Size: a a a

2020 December 16

VG

Vadim Goncharov in Modern::Perl
мне вот в AnyEvent не хватает "отложить вот этот вызов на следующую итерацию лупа"
источник

W

Warstone in Modern::Perl
Эм... Почти любой луп имеет delay
источник

W

Warstone in Modern::Perl
В промисах, насколько я помню, выполнение промиса будет в следующей итерации лупа.
источник

VG

Vadim Goncharov in Modern::Perl
Warstone
Эм... Почти любой луп имеет delay
ну вот где он в AE ?
источник

b

basiliscos in Modern::Perl
Warstone
В промисах, насколько я помню, выполнение промиса будет в следующей итерации лупа.
да
источник

W

Warstone in Modern::Perl
Vadim Goncharov
ну вот где он в AE ?
Так AE не луп. Он прокладка.
источник

b

basiliscos in Modern::Perl
за счёт того, что async I/O операцию ты уже зашпулил в низлежащий уровень
источник

W

Warstone in Modern::Perl
Ну и никогда не пользовался АЕ, у нас UE
источник

VG

Vadim Goncharov in Modern::Perl
ах_ты_хитрая_жопа.jpg
источник

W

Warstone in Modern::Perl
Ну а зачем мне медленные лупы, если есть быстрый?
источник

b

basiliscos in Modern::Perl
Vadim Goncharov
ну вот где он в AE ?
AE::postpone {}
источник

a

allter in Modern::Perl
С помощью промисов можно описать и саморекурсивный алгоритм без I/O, типа факториала. И при правильной реализации промисов он всё равно должен быть стекобезопасным.
источник

VG

Vadim Goncharov in Modern::Perl
basiliscos
AE::postpone {}
хоба! спасибо
источник

W

Warstone in Modern::Perl
basiliscos
Тут "композицируемость" достигается за счёт того, что колбэк 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

Vadim Goncharov in Modern::Perl
мне чот казалось, postpone был разовый при инициализации
источник

a

allter in Modern::Perl
Warstone
На самом деле... Если все 3 варианта выглядят нормально, то это проблема примера. Надо передумывать.
Просто добавьте в пример обработку таймаутов запросов. :) Или параллельный грабинг в N параллельных запросов с учётом возможных ошибок.
И сразу и промисов, и async/await, и колбэков станет не хватать, в плане того, что для того, что бы описать такой алгоритм ресурсобезопасно, надо будет явно прокидывать ссылки на живость типа AbortController, введённого у JavaScript`щиков.
источник

SZ

Sergey Zhmylove in Modern::Perl
Warstone
На самом деле... Если все 3 варианта выглядят нормально, то это проблема примера. Надо передумывать.
На самом деле... Нахер это всё нужно, если эти запросы не распараллелить? Почему не написать просто while ($url_next) {get $url_next; $urn_next = $response->json->{next}; push @data, $response->json->{data}} ?
Нам же нечего больше делать, пока ждём ответа
источник

W

Warstone in Modern::Perl
allter
Просто добавьте в пример обработку таймаутов запросов. :) Или параллельный грабинг в N параллельных запросов с учётом возможных ошибок.
И сразу и промисов, и async/await, и колбэков станет не хватать, в плане того, что для того, что бы описать такой алгоритм ресурсобезопасно, надо будет явно прокидывать ссылки на живость типа AbortController, введённого у JavaScript`щиков.
ConcellationToken в C# и прочие радости.
источник

b

basiliscos in Modern::Perl
Warstone
На самом деле... Если все 3 варианта выглядят нормально, то это проблема примера. Надо передумывать.
Future нормально композицируется, поверь, я в прошлом сделал 1 воплне успешный проект на нём, и там всё работало, не текло, ошибки норм. обрабатывались. Потому что Future- это монада ))). Ну опять-таки чуть удобней синтаксически промис, за счёт того, что делать "потом" в коде откладывается.
источник

W

Warstone in Modern::Perl
Да я верю что не течет и т.д. Я исключительно про читабельность сейчас.
источник