TK
И энумы ещё
Size: a a a
2021 April 28
CD
Заворачиваемый может не предоставлять интерфейс проверки на null потому что никогда не null
TK
Не заворачивай ничем, кроме Api NullableFn с проверкой, иначе ты нарушаешь инвариант типа и инкапсуляция перестаёт работать
CD
Да, ADT отлично заменяют наследование (вообще-то ADT не может расширен извне определения)
r
Э... То есть проблема в том, что мы зачем-то пытаемся обернуть null в ненуллабельный тип? А зачем?
CD
Нет, смотри. Создание NullableFn<void()> должно запросить IsNull у заворачиваемого объекта, но заворачиваемый объект может не иметь такой проверки вообще
CD
Представь, что ты Fn в NullableFn кладешь
r
Ну значит там не может быть null. Не понимаю как это связано с "Потому что внутри not null лежит null"
CD
То есть создание NullableFn не может проверять аргумент на null, потому что аргумент может не поддерживать это
r
Нуллабельный тип, который нельзя проверить на нуллабельность? Ну его нафиг это ООП, уйду в функциональщину.
CD
Ну тебе, видимо, завтипы нужны, чтобы подсовывать операции под зависимость вместо dyn Hueta
TK
Нуллабельность может существовать только у указателей. Если необходимо определять свои указатели, то для них существует CoerceUnsized для преобразования в сырые. Более общий способ определения, нерабочий - impl IsNull, в котором нужно уметь вернуть bool.
[
Кстати, про ADT. Это тип-сумма что ли?
CD
[
Всё, понял. А то я английский вариант вчера впервые услышал
CD
Ты лучше объясни, каким образом трейты могут исправлять случаи использования динамического полиморфизма, когда они ортогональные
TK
Кривым или непроторенным, но таких случаев мало
TK
В сравнении с подавляющим большинством остальных
CD
А перепутать енум и интерфейс это вообще кайфовый способ рефакторить потом миллион лет
TK
Я не знаю, как ты умудришься их перепутать