с#
в хэшмапе коллизии разрешаются. А если ты сам возьмёшь хэш, это уже на твоей совести
а как хешмап с ними разберется ?
Size: a a a
2020 October 26
с#
ну в плане разве он не может выдать не то значение ?
v
ноу. это ж просто инстанс класса
Спасибо!
QH
а как хешмап с ними разберется ?
окей гугл, как хэшмэп разрешает коллизии?
QH
ну в плане разве он не может выдать не то значение ?
нет конечно, всё чётко
D
Не совсем понятно какую задачу человек решает на уровне выше. Нет ли тут XY Problem
АЕ
Раз уж пошли про kotlinx.serialization. Как можно сделать свой сериализатор, который при десериализации списка будет из него выкидывать элементы, на которых десериализация падает с исключением? Я сделал вариант, но почему-то очень много классов в библиотеке internal, и пришлось скопировать всю иерархию ListLikeSerializer для этого
AN
Переслано от Bogdan Panchenko
Как аннотацию отличит от декоратора ?
AN
AN
AN
AN
AN
AN
Вопрос, который поднял Богдан хороший и тут уже обсуждали. Пока декоратор не меняет сигнатуру, с ним все в порядке. И он на самом деле семантически от аннотации не отличается. А вот если меняет, то аргумент становится актуальным.
IP
ну тут такая же проблема, как в шарпе
IP
у них проперти с большой буквы, приватной филды с маленькой да еще с подчеркиванием. кто назвал филд с большой буквы - ну дурак
IP
а вообще, защищать пользователей гитхаба - бред. что-то настолько подробно ревьюить в гитхабе, что важна разница между аннотацией/декоратором, - да никто так не делает. нужно что-то прям подробно глянуть - ну checkout'те ветку
AN
а вообще, защищать пользователей гитхаба - бред. что-то настолько подробно ревьюить в гитхабе, что важна разница между аннотацией/декоратором, - да никто так не делает. нужно что-то прям подробно глянуть - ну checkout'те ветку
Да нет, это тоже аргумент. Если они по разному работают
IP
в крайнем случае - есть монстр в лице upsource, где мощная поддержка синтаксиса для ревью
AN
Переслано от Alexander Nozik
Ну вот у нас сейчас есть data и suspend. Пока есть только они, все ок. Но давайте смотреть более широкую картину:
* const val
* Composable
* val class
Получаем уже кучу разны штук, которые хочется воткнуть и почти на каждое надо городить ключевое слово. Уж лучше сделать единый @-синтаксис (это уже было в груви). И пусть будет единообразоно.
НО! Есть совершенно правильный аргумент @SchFuntik о том, что мы должны иметь возможность глядя на этот модификатор, понимать, что он делает. Если каждый придумывает свои декораторы и эти декораторы меняют семантику как хотят - это беда. Запиши себе для созвона.
* const val
* Composable
* val class
Получаем уже кучу разны штук, которые хочется воткнуть и почти на каждое надо городить ключевое слово. Уж лучше сделать единый @-синтаксис (это уже было в груви). И пусть будет единообразоно.
НО! Есть совершенно правильный аргумент @SchFuntik о том, что мы должны иметь возможность глядя на этот модификатор, понимать, что он делает. Если каждый придумывает свои декораторы и эти декораторы меняют семантику как хотят - это беда. Запиши себе для созвона.