VP
На самом деле, в посте Романа вполне конкретно написано, почему не Either, если кто читал внимательно
Видимо, не все это заметили
Size: a a a
2020 June 10
AN
Видимо, не все это заметили
Потому что есть-или-нет, то для этого есть нулябли и Either не нужОн. Если вариантов больше двух, то силед иерархии значительно более выразительны, чем монструозные Either8. Вторая часть - это уже мой хумбл опинион.
QH
Потому что есть-или-нет, то для этого есть нулябли и Either не нужОн. Если вариантов больше двух, то силед иерархии значительно более выразительны, чем монструозные Either8. Вторая часть - это уже мой хумбл опинион.
> монструозные Either8
отсылка засчитана :)
отсылка засчитана :)
AN
> монструозные Either8
отсылка засчитана :)
отсылка засчитана :)
Что думаю, то говорю :)
VP
Потому что есть-или-нет, то для этого есть нулябли и Either не нужОн. Если вариантов больше двух, то силед иерархии значительно более выразительны, чем монструозные Either8. Вторая часть - это уже мой хумбл опинион.
Даже там приведён весьма типичный пример есть-или-нет, где "нет" это не просто "нет", а "нет" с дополнительной информацией. Почему бы их не обобщить?
Нормальный use-case для Either8 я не знаю, так что согласен.
Нормальный use-case для Either8 я не знаю, так что согласен.
AN
Даже там приведён весьма типичный пример есть-или-нет, где "нет" это не просто "нет", а "нет" с дополнительной информацией. Почему бы их не обобщить?
Нормальный use-case для Either8 я не знаю, так что согласен.
Нормальный use-case для Either8 я не знаю, так что согласен.
Это вопрос проектирования. Как я понял Романа, просто в котлин надо проектировать АПИ таким образом, чтобы null был смысловым.
VP
Это вопрос проектирования. Как я понял Романа, просто в котлин надо проектировать АПИ таким образом, чтобы null был смысловым.
Проблема в том, что null не может нести смысла больше, чем "что-то пошло не так".
И кстати превращение неожиданного null в качественное сообщение о логической ошибке - это дополнительный код, который придётся писать каждый раз.
А если возвращать
И кстати превращение неожиданного null в качественное сообщение о логической ошибке - это дополнительный код, который придётся писать каждый раз.
А если возвращать
Either<L, R>, где у L есть адекватный toString(), то всё становится проще.VP
А ещё исключения полезны везде, где можно забыть проверить результат. В идеале это и есть I/O, но не всегда.
AN
Мне доктрина Романа больше нравится. Исключения кидаются в исключительных ситуациях и обрабатываются в одном месте.
AS
Мне кажется, что во многом
Result отлично замещает Either. Смысл одинаковый, но намного более понятно тем, кто не знаком с функциональщиной.QH
Мне кажется, что во многом
Result отлично замещает Either. Смысл одинаковый, но намного более понятно тем, кто не знаком с функциональщиной.у result left может быть только throwable. Для ситуаций, которые всегда нужно обрабатывать, это не имеет смысла
VP
Мне кажется, что во многом
Result отлично замещает Either. Смысл одинаковый, но намного более понятно тем, кто не знаком с функциональщиной.Result вообще ни разу не замена Either, там типобезопасности ноль. Как вы будете обрабатывать Throwable?
AS
Ладно, я больше смотрел в сторону резалта как в расте 🙂
VP
Так это и есть Either 😄
AS
Я больше про названия, если честно
VP
Но в расте ещё и альтернатив-то нет
QH
Но в расте ещё и альтернатив-то нет
Есть. Паники можно ловить, почти как эксепшены. Ну и свои а-ля силеды — вообще тривиально.
AS
Но в расте ещё и альтернатив-то нет
Ну можно сделать свой Either, но его нельзя через
? отловить вродеQH
Просто там чётко разделили: паники — для ошибок программирования, резалты и опшеналы — для обработки успеха-неуспеха.
VP
Ну можно сделать свой Either, но его нельзя через
? отловить вродеО, точно, надо будет это вспомнить, когда кто-то будет заявлять, что в котлине nullability прибили гвоздями в язык