VG
мне вот в AnyEvent не хватает "отложить вот этот вызов на следующую итерацию лупа"
Size: a a a
2020 December 16
W
Эм... Почти любой луп имеет delay
W
В промисах, насколько я помню, выполнение промиса будет в следующей итерации лупа.
VG
Эм... Почти любой луп имеет delay
ну вот где он в AE ?
b
В промисах, насколько я помню, выполнение промиса будет в следующей итерации лупа.
да
W
ну вот где он в AE ?
Так AE не луп. Он прокладка.
b
за счёт того, что async I/O операцию ты уже зашпулил в низлежащий уровень
W
Ну и никогда не пользовался АЕ, у нас UE
VG
ах_ты_хитрая_жопа.jpg
W
Ну а зачем мне медленные лупы, если есть быстрый?
b
ну вот где он в AE ?
AE::postpone {}
a
С помощью промисов можно описать и саморекурсивный алгоритм без I/O, типа факториала. И при правильной реализации промисов он всё равно должен быть стекобезопасным.
VG
AE::postpone {}
хоба! спасибо
W
Тут "композицируемость" достигается за счёт того, что колбэк
get_all(100_500, sub {
my $ok = shift;
...
})
vs
get_all(100_500)
->then(
sub { } # succes branch
sub { } # fail branch
)
или
get_all(100_500)
->then(sub { ... })
->else(sub { ... })
```
on_complete передаётся во внуть ф-ции. В промисах - это вовне. Поэтому, как по мне, промисы удобней. Но по сути, да, согласен, что они эквивалентны. Т.е.get_all(100_500, sub {
my $ok = shift;
...
})
vs
get_all(100_500)
->then(
sub { } # succes branch
sub { } # fail branch
)
или
get_all(100_500)
->then(sub { ... })
->else(sub { ... })
```
На самом деле... Если все 3 варианта выглядят нормально, то это проблема примера. Надо передумывать.
VG
мне чот казалось, postpone был разовый при инициализации
a
На самом деле... Если все 3 варианта выглядят нормально, то это проблема примера. Надо передумывать.
Просто добавьте в пример обработку таймаутов запросов. :) Или параллельный грабинг в N параллельных запросов с учётом возможных ошибок.
И сразу и промисов, и async/await, и колбэков станет не хватать, в плане того, что для того, что бы описать такой алгоритм ресурсобезопасно, надо будет явно прокидывать ссылки на живость типа AbortController, введённого у JavaScript`щиков.
И сразу и промисов, и async/await, и колбэков станет не хватать, в плане того, что для того, что бы описать такой алгоритм ресурсобезопасно, надо будет явно прокидывать ссылки на живость типа AbortController, введённого у JavaScript`щиков.
SZ
На самом деле... Если все 3 варианта выглядят нормально, то это проблема примера. Надо передумывать.
На самом деле... Нахер это всё нужно, если эти запросы не распараллелить? Почему не написать просто
Нам же нечего больше делать, пока ждём ответа
while ($url_next) {get $url_next; $urn_next = $response->json->{next}; push @data, $response->json->{data}} ? Нам же нечего больше делать, пока ждём ответа
W
allter
Просто добавьте в пример обработку таймаутов запросов. :) Или параллельный грабинг в N параллельных запросов с учётом возможных ошибок.
И сразу и промисов, и async/await, и колбэков станет не хватать, в плане того, что для того, что бы описать такой алгоритм ресурсобезопасно, надо будет явно прокидывать ссылки на живость типа AbortController, введённого у JavaScript`щиков.
И сразу и промисов, и async/await, и колбэков станет не хватать, в плане того, что для того, что бы описать такой алгоритм ресурсобезопасно, надо будет явно прокидывать ссылки на живость типа AbortController, введённого у JavaScript`щиков.
ConcellationToken в C# и прочие радости.
b
На самом деле... Если все 3 варианта выглядят нормально, то это проблема примера. Надо передумывать.
Future нормально композицируется, поверь, я в прошлом сделал 1 воплне успешный проект на нём, и там всё работало, не текло, ошибки норм. обрабатывались. Потому что Future- это монада ))). Ну опять-таки чуть удобней синтаксически промис, за счёт того, что делать "потом" в коде откладывается.
W
Да я верю что не течет и т.д. Я исключительно про читабельность сейчас.