W
Эм... А почему async/await мешают с Promise'ами? Это-же непересекающиеся вещи. Вернее async/await должны нахрен выкинуть промисы
Size: a a a
2020 December 16
b
Эм... А почему async/await мешают с Promise'ами? Это-же непересекающиеся вещи. Вернее async/await должны нахрен выкинуть промисы
a/a же работает поверх промисов... по крайней мере у Эванса. По идее это только сахарок надо промисами должен быть, да, возможно, скрывающий совсем промисы.
W
Ну... Я привык к C# версии a/a где нету промисного недоразумения, за что я им безмерно благодарен.
W
И, как по мне, надо идти именно по этому пути, так как промисы - это элегантный способ выстерлить себе в пятку. Идти сможешь, в принципе - дойдешь, но будет больно и потом будет заражение.
SZ
Ну... Я привык к C# версии a/a где нету промисного недоразумения, за что я им безмерно благодарен.
Что за недоразумение, в двух словах?
SZ
allter
А немного не дочитал. Он вернёт
, что бы это не значило. :)
bless [13], "main"
, что бы это не значило. :)
Может тебе назвать его Promise::Async ? xD
W
Промисы. Я уже писал тут. Если тебе надо сделать обработку чуть сложнее чем просто ответ от сервера, то промисы превращаются в ад.
W
Могу привести конкретно свой пример. Правда кода, к сожалению, не сохранилось...
a
Может тебе назвать его Promise::Async ? xD
Там на Препане кто-то уже кинул вопрос про связь с Эвансовским Future::AsyncAwait (который XS, что мне не подходит). Не хотелось бы вводить лишнюю путаницу.
SZ
Могу привести конкретно свой пример. Правда кода, к сожалению, не сохранилось...
Было бы здорово! Или хотя бы ссылку
a
Промисы. Я уже писал тут. Если тебе надо сделать обработку чуть сложнее чем просто ответ от сервера, то промисы превращаются в ад.
Промисы это всё же проще чем колбэки.
А так, известные баги промисов - это то, что создание промиса - это сайдэффект, а так же то, что без дополнительной машинерии они не обеспечивают ресурсобезопасность (в частности, для банального сценария действий с таймаутами).
А так, известные баги промисов - это то, что создание промиса - это сайдэффект, а так же то, что без дополнительной машинерии они не обеспечивают ресурсобезопасность (в частности, для банального сценария действий с таймаутами).
W
Там суть была в том что надо скачать список с сети (список пагинирован. То есть сколько запросов надо - неизвестно) и потом для каждого элемента сделать от 2 до 4-х запросов с возможностью отфильтровать элементы на каждой стадии.
Я, ради прикола, написал это на Mojo::Promise'ах, проклял это все, так как на коллбеках было-бы и читабельней и проще и кода меньше.
Я, ради прикола, написал это на Mojo::Promise'ах, проклял это все, так как на коллбеках было-бы и читабельней и проще и кода меньше.
W
allter
Промисы это всё же проще чем колбэки.
А так, известные баги промисов - это то, что создание промиса - это сайдэффект, а так же то, что без дополнительной машинерии они не обеспечивают ресурсобезопасность (в частности, для банального сценария действий с таймаутами).
А так, известные баги промисов - это то, что создание промиса - это сайдэффект, а так же то, что без дополнительной машинерии они не обеспечивают ресурсобезопасность (в частности, для банального сценария действий с таймаутами).
Это заблуждение. Промисы не дают простоту, они дают тебе контракт и кучу шлака вокруг.
SZ
Там суть была в том что надо скачать список с сети (список пагинирован. То есть сколько запросов надо - неизвестно) и потом для каждого элемента сделать от 2 до 4-х запросов с возможностью отфильтровать элементы на каждой стадии.
Я, ради прикола, написал это на Mojo::Promise'ах, проклял это все, так как на коллбеках было-бы и читабельней и проще и кода меньше.
Я, ради прикола, написал это на Mojo::Promise'ах, проклял это все, так как на коллбеках было-бы и читабельней и проще и кода меньше.
Да, такое на коллбэках было бы в разы проще и понятнее.
Как по мне, промисы больше подходят для «линейных» алгоритмов, чем для ветвлений.
Как по мне, промисы больше подходят для «линейных» алгоритмов, чем для ветвлений.
SZ
Спасибо за пояснения
W
Ну а на a/a это было-бы в разы проще. Чтение с пагинацией:
var request = construct_my_request();
List<result> results = new List<result>();
var request_results;
int page_num = 0;
do {
request_results = await request.Invoke(page_num++);
results.Add(request_results);
} while(request_results.Count == PAGE_LIMIT);a
Эм... А почему async/await мешают с Promise'ами? Это-же непересекающиеся вещи. Вернее async/await должны нахрен выкинуть промисы
Потому что ты можешь написать async функцию с рекурсивным await самой себя, и стекобезопасность данного финта зависит от конкретной реализации промисов.
W
allter
Потому что ты можешь написать async функцию с рекурсивным await самой себя, и стекобезопасность данного финта зависит от конкретной реализации промисов.
Эм... И что? Рекурсивный вызов функции всегда проблема. И к промисам она не имеет никакого отношения. Более того если у тебя через промисы нету too many recursion, то тебе надо это делать.
a
Это заблуждение. Промисы не дают простоту, они дают тебе контракт и кучу шлака вокруг.
Ну, вот за счёт контракта ты можешь их комбинировать. Но вот когда речь идёт об отменяемости, то да, голых промисов для композабельности недостаточно - нужны таски/cancelable promises.
W
allter
Ну, вот за счёт контракта ты можешь их комбинировать. Но вот когда речь идёт об отменяемости, то да, голых промисов для композабельности недостаточно - нужны таски/cancelable promises.
Вы вообще поняли о чем я говорил?..