Perché la maggior parte delle implementazioni di ReactiveX sono basate su push?

1

Sentiti libero di correggere la mia cronologia, ma per quanto ho capito, Rx e il Manifesto Reattivo risalgono a C # e alle sue Reactive Extensions, che usa la messaggistica push (basata sulla callback), in modo che i Publishers chiamino Subscriber metodi con valori, piuttosto che restituire valori a un ambito di sottoscrizione come un iteratore. Questo è un po 'sorprendente, visto che C # ha meccaniche iteratore molto mature e forti come LINQ, per non parlare del fatto che è nato asincrono-asincrono, che è decisamente pull.

Sto progettando una libreria reattiva in Hacklang, e mentre per la questione di quale stile è più fondamentale, il campo guidato dai messaggi potrebbe averlo - si potrebbe dire che CPS è basato sui messaggi, o che lo scheduler è veramente un relè di messaggi, e ho potuto vedere il tuo punto - non vedo davvero il vantaggio.

Hack abbraccia strettamente il modello async-await. Una conseguenza è che spingere i messaggi in modo asincrono è in realtà eccezionalmente difficile. Quasi tutti gli oggetti asincroni sono progettati per essere await ed e producono una dipendenza dal valore, quindi è difficile per qualsiasi codice impostare e dimenticare un callback dal quale non dipende.

Tuttavia, è stata davvero una gioia programmare con iteratori, non un ostacolo. Al suo interno c'è il AsyncGenerator , che deriva dalle funzioni asincrone [read: pigro]. Sono iterati da un costrutto foreach-like ( await as ), quindi ciò significa che " subscriber "o chiamando scope può break out quando vuole, chiedere elementi ogni volta che lo desidera, try-catch , throw , restituire i propri valori in sospeso, diventare un iteratore - qualsiasi cosa il linguaggio consenta al codice sincrono. Questo livello di libertà dell'abbonato, in particolare la richiesta di elementi a volontà, suona come la direzione dei flussi reattivi, che è indicativa dei problemi che risolve. Con gli iteratori, però, è già pronto.

Tornando a C #, con la sua già impressionante suite di meccanismi iteratori, perché ha optato per i callback per Reactive Extensions? La loro decisione ha posto le basi per la spinta a dominare? Esiste una motivazione distinta, familiare, espressiva, ecc. Per la prevalenza del messaggio push in Reattivo?

Modifica: Ah, InteractiveX era il nome del concetto che stavo cercando: sostituire IObservable con IEnumerable . È davvero più oscuro - l'organizzazione ReactiveX pubblica solo un'implementazione JS - e se capisco presentazione di Bart de Smet su Ix nel 2011 , alcuni operatori non sono implementati" in modo interattivo ", ma piuttosto si ottengono convertendo in IQueryable , costruendo l'albero delle espressioni e tornando a IEnumerable per scorrere.

Forse a causa dell'equivalenza, solo uno tra ReactiveX e InteractiveX era abbastanza buono? Forse è innaturale lavorare con? Bart de Smet menziona il ISubject <-> IBuffer duale, che ho trovato illuminante. Non c'è molta documentazione al di fuori del suo discorso, che non discute molto delle motivazioni, quindi sto ancora prendendo alcuni scatti al buio un po '.

    
posta concat 16.04.2017 - 17:36
fonte

0 risposte

Leggi altre domande sui tag