В статье по этой части как раз фигня :) Класс Exception прекрасно описывает ошибки. Вот бросать исключения действительно нужно не всегда
Ты типа предлагаешь просто возвращать объект исключения, без throw?
Roman
Bonart
и в таску уже прибита гвоздями асинхронность, которая тебе не всегда нужна
Task.FromResult и Task.FromException - и все синхронно
Bonart
мой поинт короче в том, что в данном случае сова на глобус натягивается легко, но все равно это своа и глобус
Фундаментальным свойством сюжета "сова и глобус" является трудность натяжения. Если трудности нет это НЕ сова и глобус
Bonart
https://github.com/Kirill-Maurin/FluentHelium/blob/master/FluentHelium.Base/Extensions/TaskExtensions.cs
Bonart
Метод SelectMany биндит таску к таске
Roman
Фундаментальным свойством сюжета "сова и глобус" является трудность натяжения. Если трудности нет это НЕ сова и глобус
вот тут не согласен. Во всяком случае, под натягиванием совы на глобус я имею ввиду использование абстракции не по прямому назначению. Это может происходить легко, но рано или поздно за это приходится платить
Bonart
Метод Select - синхронный код к таске
Bonart
вот тут не согласен. Во всяком случае, под натягиванием совы на глобус я имею ввиду использование абстракции не по прямому назначению. Это может происходить легко, но рано или поздно за это приходится платить
Так абстракция в данном случае та же самая. В этом весь смысл
Roman
более того, когда читаешь код и видишь, что он возвращает Task<User>, подразумеваешь, что этот метод асинхронно достает юзера. Ничто здесь в сигнатуре не отражает ожидаемые возможные ошибки в отличие от Result<User, ValidationError>
Roman
Так абстракция в данном случае та же самая. В этом весь смысл
не та же самая. Таска в первую очередь про асинхронность, а не про ветви исполнения. И ее свойство Exception на уровне типов не дает необходимой информации
Bonart
более того, когда читаешь код и видишь, что он возвращает Task<User>, подразумеваешь, что этот метод асинхронно достает юзера. Ничто здесь в сигнатуре не отражает ожидаемые возможные ошибки в отличие от Result<User, ValidationError>
Так ничего подобного - Task НЕ гарантирует асинхронность, только допускает. Task не гарантирует успех - может вернуть Exception
Roman
Потому что туда можно любой эксепшн запихать, это все равно, что Result<User,Object>
Bonart
Потому что туда можно любой эксепшн запихать, это все равно, что Result<User,Object>
В данном случае это преимущество, так как ошибки в 99,9% случаев - сущность открытая. А для закрытых типов-сумм в сишарпе нет
Roman
Ладно, мы не договоримся
Bonart
Фокус в том, что тип "Result" в сишарпе есть, с ним можно работать, мы с ним уже работаем. А вот калька с функциональных языков будет тем самым натягиванием совы на глобус и аналогом checked exceptions в яве
x
это я на проекте использовал, эту либу вроде https://github.com/louthy/language-ext
я за такой вариант, всё остальное странное
Bonart
я за такой вариант, всё остальное странное
Для сишарпа монады через linq как раз идиоматичны.
Крылатый
Крылатый
Цените няку :33
x
мыш!
Крылатый
Это лиса ;P
Bonart
так кто виноват
Правильный вопрос не "кто виноват", а "что делать". Я предпочитаю внедрять новое через знакомое
Vladislav
Крылатый
Лисики они же няшы
x
Правильный вопрос не "кто виноват", а "что делать". Я предпочитаю внедрять новое через знакомое
я даже не знаю, видел ли когда-нибудь чтобы с Task работали через кваери компрехеншен. То есть я например да, я сделал из него тоже монаду и так работаю - но не для того чтобы ошибки собирать (точнее, не только для этого) - но в синхронном коде у меня Result используется. Просто ни то, ни другое, увы неидиоматично для среднего c#
Bonart
я даже не знаю, видел ли когда-нибудь чтобы с Task работали через кваери компрехеншен. То есть я например да, я сделал из него тоже монаду и так работаю - но не для того чтобы ошибки собирать (точнее, не только для этого) - но в синхронном коде у меня Result используется. Просто ни то, ни другое, увы неидиоматично для среднего c#
У таски с остальным шарпом оверхед нулевой
x
кстти по поводу оверхедда: Task это reference тип
x
Bonart
ась?
В смысле возврат таски для "среднего сишарписта" никаких когнитивных трудностей не создаст
Bonart
кстти по поводу оверхедда: Task это reference тип
Да, если это будет важно, то ValueTask, а потом и Result подтянется
x
В смысле возврат таски для "среднего сишарписта" никаких когнитивных трудностей не создаст
по личному опыту пропаганды, когнитивную трудность создаёт не возвращаемый тип (тут все просто, Option и Result на раз-два понимаются), а то что потом с ними делать надо. Концепция монады без m-word
Bonart
по личному опыту пропаганды, когнитивную трудность создаёт не возвращаемый тип (тут все просто, Option и Result на раз-два понимаются), а то что потом с ними делать надо. Концепция монады без m-word
Так с таском все в первом приближении знают что делать
Bonart
Надо только народ к лотку, то есть к LINQ приучить
x
Так с таском все в первом приближении знают что делать
ну например, то что надо делать await вместо прямой достачи таск.резалт?
x
так всё равно не запрещено - бери и доставай
x
x
сразу возникает вопрос: как мне поиметь значение?
x
и это - хороший, правильный вопрос )
Bonart
сразу возникает вопрос: как мне поиметь значение?
Авайтом или селектом. Напрямую звать Result из таска давно уже не модно
x
так надо ли оно
Vladislav
что именно? луковая архитектура? а что теперь модно
Пайплайны где в центре домен. Тяжело сказать
Bonart
так надо ли оно
Зато интероперабельность с тем что есть - полная, дополнительная когнитивная нагрузка отсутствует, с массой существующего кода стыкуется на раз. Проблемы API известны и обходятся на уровне рефлекса.
Roman
теперь можно гордо говорить, что в жаве есть тайп инференс
Roman
Не то чтобы это джава чатик, но всего 23 года понадобилось чтобы внедрить такую плёвую фичу
Vasily
Кароч. Помимо полезности фич(или бесполезности), еще логично вводить понятие сопротивления среды изменениям
Vasily
Условно, если чувак говнокодит энтерпрайз n лет, ему нелегко объяснить, зачем использовать что-то новое, если старое и так работает
Bonart
Условно, если чувак говнокодит энтерпрайз n лет, ему нелегко объяснить, зачем использовать что-то новое, если старое и так работает
Угу, все через опу, но типа работает
Bonart
(на самом деле нет)
Bonart
Просто то, что не работает по старому считается непреодолимым
Vasily
Вообще, конечно, было бы интересно посмотреть научные исследования на данную тему
Vasily
И почему такая изменчивая среда, как разработка ПО, имеет такое свойство сопротивляться изменениям
Bonart
Можно и без этого - модульность это "слишком узкая тема для доклада", "переход на микросервисы" - в самый раз. Ничего, что второе - частный случай первого?
Bonart
И почему такая изменчивая среда, как разработка ПО, имеет такое свойство сопротивляться изменениям
Потому что это люди, а человеческий мозг имеет массу костылей
Ayrat
Вообще, конечно, было бы интересно посмотреть научные исследования на данную тему
я тебе и так расскажу
"Раньше было лучше"
"Эта молодёжь слушает плохую музыку"
"Всё что делается сейчас описано в трудах 90ых(80ых(70ых(продолжаем до Аристотеля))), поэтому не нужно!"
Bonart
И некоторые вещи категорически контринтуитивны
Vasily
Ну было бы интересно это описать в терминах той же теории поля
Vasily
Или распространения волн в вязкой среде
x
💩
Анна
https://www.facebook.com/pavel.e.stroganov/posts/1302746253210687
Vasily
Комиксы огонь
Vasily
Довольно точно подмечен принцип локальной оптимизации, превалирующей в бизнесе
Ayrat
Ayrat
там один критерий - цена контракта. Если хер знает кто предлагает меньше, обязан его выбрать
Крылатый
Тест
Крылатый
Хм, отправка тормозит
Крылатый
там один критерий - цена контракта. Если хер знает кто предлагает меньше, обязан его выбрать
Зпвисит от закона, но если формальные требования выполнены, то да.
Bonart
там один критерий - цена контракта. Если хер знает кто предлагает меньше, обязан его выбрать
Не один - опытный закупщик формирует требования так, чтобы ни один тушкан не проскочил
Ayrat
Не один - опытный закупщик формирует требования так, чтобы ни один тушкан не проскочил
К сожалению, такое сплошь и рядом