Funkcionální programování ve Scale 3. (diskuse)

[ava]

Díky za další parádní díl. Tohle už se četlo o trochu snadněji, než ten minulý :) Je to pro mě mimořádné srovnání s RxJava, jen si v hlavě pořád nedokážu úplně srovnat push-based přístup RxJavy (předchozí článek řetězu tlačí data do dalšího pomocí OnNext) (i když v reakci na problémy s backpressure tam přidali možnost kombinovaného push/pull based), a - asi - pull based přístupu scalaz-stream (následující články řetězu tahají data od předchozích)? Nebo je celé tohle dělení umělé? A jaký je vlastně rozdíl mezi pull-based přístupem a obyčejnými streamy? To jsou otázky, které mi v noci nedají spát :) Těším se na další díly.

[Radek Miček]

pull based přístupu scalaz-stream (následující články řetězu tahají data od předchozích)

Ano, scalaz-stream je pull based. Push lze nasimulovat například pomocí fronty:

val p = (Process(1, 2, 3).toSource ++ eval_(Task.delay(println("print")))).repeat
val processItem: Sink[Task, Int] = io.stdOutLines.contramap(_.toString)

// Vytvorime frontu.
val q = async.unboundedQueue[Int]

// Prvky produkovane procesem p posleme do fronty.
p.to(q.enqueue).run.runAsync(x => println("enqueue end"))

// q.dequeue je proces prvku z fronty.
// Prvky z fronty posilame do Sinku processItem, ktery prvky zpracovava.
// Az jsou prvky zpracovany (nebo po vyhozeni vyjimky) frontu zavreme
// -- zavreni fronty zajisti ukonceni procesu, jenz dava prvky do fronty
// -- tj. ukonceni p.to(q.enqueue).run.runAsync(x => println("enqueue end")).
(q.dequeue.to(processItem).take(2) onComplete eval_(q.close)).run.run

Kód obvykle několikrát vypíše řetězec print – počet vypsaných řetězců print závisí na tom, jak rychle se prvky produkované p posílají do fronty q. Kromě neomezené fronty async.unboundedQueue existuje i omezená fronta async.boundedQueue.

A jaký je vlastně rozdíl mezi pull-based přístupem a obyčejnými streamy?

Myslím, že obyčejné streamy jsou také pull based.