Комментарии 23
после нескольких месяцев отсутствия использования .Net/C#
это прям вот сразу ужас какой-то!
А по содержанию, понятно что это перевод, но посмотрите что вам предлогают:
DoFirstThing().ContinueWith(_ => DoSecondThing()).ContinueWith(_ => DoThirdThing());
Это называется "современный стиль кодирования", я так понимаю = пишите так чтобы никто ничего не понял, пихайте как можно больше вызовов функций в одну строчку, чем больше напихали, тем современнее!
Например тут в зависимости от того как считать лямбды или 5 или 7 вызовов в одной строчке, не особо впечатляет.
Это перевод статьи из 2012 года?
Не пишите такой код как в статье.
Типичный is, но в джс асинк появился раньше чем в питоне, но в последнем в отличии от джс , да и в других языках асинк это внатуре асинк, а не промисы как последовательная очередь заданий. Кста в последней строке джс кода всё встанет и будет ждать результата, уж если это какая-то паралельная работа код должен не стоять, а ехать, а для ожидания результата нужен обработчик. Цепочку можно как написано выше в первом коментарии или task. When ещё например, куча вариантов task from result
Код не эквивалентен ни разу.
Js вызываеться последовательно цепочкой then.
Эквивалентный вызов был бы.
DoFirstThing().ContinueWith(_ => DoSecondThing().ContinueWith(_ => DoThirdThing()));
Перестановка одной скобки в корень бы поменяло поведение. И никакой UnWrap вам тут был бы не нужен.
С чего бы цепочка then должна быть эквивалентной вложенным ContinueWith? Это во-первых.
А это-вторых, если потребуется вернуть Task (а его требуется возвращать почти всегда во избежание утери обратного давления) - вам снова понадобятся Unwrap.
С чего бы цепочка then должна быть эквивалентной вложенным ContinueWith?
интересно а кто по вашему определяет эквивалентность? Это должно быть чье-то мнение по вашему???
По моему, объективным критерием является эквивалентность поведения цепочек, раз ПОВЕДЕНИЕ вложенных ContinueWith эквивалентно поведению цепочки then можно утверждать что эти конструкции разных языков эквивалентны, мне кажется.
Так как вы определяете эквивалентность?
Так же, по поведению.
then возвращает плоский Promise
вложенный ContinueWith не возвратит вам плоский Task
then возвращает плоский Promise
эквивалентность очевидно не может быть полной потому что сравниваются разные языки, если следовать вашей логике то можно вообще залезть в бутылку и сказать что они не эквивалентны потому что один возвращает Промис, а другой Таск.
Поэтому... вряд ли это можно считать конструктивным аргументом.
В данном случае это вы зачем-то лезете в бутылку и игнорируете второй аспект вопроса.
Что делать, если цепочка на этом месте не закончилась, и должна быть продолжена за пределами метода?
Task Foo()
{
DoFirstThing().ContinueWith(_ => DoSecondThing().ContinueWith(_ => DoThirdThing()));
return ???;
}
Вы, конечно, можете сказать: опять я неправильно применил эквивалентность, и цепочку надо растить вглубь:
void Foo(Action<Task> next)
{
DoFirstThing().ContinueWith(_ => DoSecondThing().ContinueWith(_ => DoThirdThing().ContinueWith(next)));
}
Да, так будет работать, но в чём тут вообще смысл использования Task?
Да, так будет работать, но в чём тут вообще смысл использования Task?
ну насколько я понимаю, смысл в том чтобы продемонстрировать как написать код так чтобы задания 1,2,3 завершались в правильном порядке, поскольку мы не знаем зачем нам чтобы они завершелись в правильном порядке, дальше(!) смысл искать бесполезно!
с точки зрения поддержания этого порядка цепочка then будет эквивалентной вложенным ContinueWith никуда лезьть не надо!
Какой вы еще хотите смысл найти? Какая разница какие там таски-промисы плоские, квадратные, зеленые... ? Или вы видите некоторую глобальность в этой примитивном вопросе организации завершений? Если так, то я этой глобальности взгляда и анализа разделить с вами не смогу, извините, для меня все просто.
прежде чем уводить дисскуссию в какие-то дебри о плоских (квадратных, зеленых, еще каких?) промисах-тасках, вы на простой вопрос попробуйте сначала ответить:
Чем плохо что задачи будут завершаться в порядке 1,3,2 ;
а не в порядке 1,2,3 ? Почему это надо исправлять? Есть у вас ответ в данном конкретном случае? Я могу конечно предположения делать, но предположения ничего не доказывают!
С чего бы цепочка then должна быть эквивалентной вложенным ContinueWith? Это во-первых.
Возражение справедливое, хотя IMHO тут начать надо (причем - не комментарий, а саму статью) с того, что метод then в JS семантически не эквивалентен методу ContinueWith в.NET даже когда ои используются внешне одинаково - ровно с одним параметром и даже если проигнорировать для простоты условия продолжения и считать, что все завершается нормально. Потому что через этот параметр передаются сущности разного типа: в then - promise, т.е. задача, а в ContinueWith - делегат, т.е. код который будет выполняться в задаче (а уж ContinueWith обернет его в задачу).
Вообще в данной статье случай рассмотрен простейший: параметр для ContinueWith поменять несложно, т.к. код соответствующих делегатов доступен. А потому я сильно сомневаюсь, что ее вообще стоило переводить. А к чему это приводит и как с этим бороться в разных более сложных случаях, например, когда доступен только Task, а не делегат, который им выполняется - это уже совсем другая история, и в комментарии ее я рассказать не берусь.
PS Поубирал минусы, которые вы тут друг другу понаставили: не по делу они IMHO.
Потому что через этот параметр передаются сущности разного типа: в then - promise, т.е. задача, а в ContinueWith - делегат, т.е. код который будет выполняться в задаче (а уж ContinueWith обернет его в задачу)
Это через какой такой параметр в then передаётся promise, т.е. задача?
doFirstThing().then(doSecondThing).then(doThirdThing)
Обратите внимание, в этом примере кода написано .then(doSecondThing), а вовсе не .then(doSecondThing())
Просто неудачно выразил мысль - слишком сократил. Если говорить точнее (и длиннее), то в ContinueWith передается делегат, не возвращающий результатата (либо делегат, возвращающий результат задачи, а не задачу, но, в любом случае - выполняющийся синхронно), а в then - функция, возвращающая promise.
Против этого возражения будут?
Дополнительно. Я в курсе, что в then можно передать нечто синхроннное (и тогда он вернет завершенный promise), а задачу, созданную ContinueWith - наоборот, заставить дождаться завершения запущенной из делегата задачи (если сделать ее дочерней, к примеру). Но все это - те самые дополнительные усложнения, выходящие за рамки статьи.
PS А кому прямо так нужен аналог Promise в C#, то для этого есть TaskCompletionSource. Но это уже другая история.
Тут у меня возражений нет, более того, именно это я и написал выше. А вот у моего оппонента, которому вы так "поубирали" минусы, возражение есть:
Какой вы еще хотите смысл найти? Какая разница какие там таски-промисы плоские, квадратные, зеленые... ?
Интересно какое возражение вы определили в этих вопросах, а главное по какой проблеме вы в них нашли возражение.
Я перестал понимать ваши комментарии.
А мне кажется вы просто не можете себе позволить признаться что немножко, самую малость, неправы.
Просто мои вопросы не допускают даже возможности абстрактных ответов, поэтому даже попытка ответить на них все ставит на свои места, и спускает с небес на землю. Поэтому вам ничего не остается кроме как ставить минусы на вопросы для которых у вас нет ответа. Мнение которого вы придерживаетесь не должно подвергаться сомнениям.
В c#5 добавлен await? Вот это новости)
Базовый вариант использования Task Unwrap