[swift-evolution] Standard ReactiveSteam definitions for Swift

[Benjamin Garrigues]

> Le 24 sept. 2017 à 21:15, Marc Schlichte via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> I hope we come up with some genuine ideas for ReactiveStreams on Swift.
> 
> For example instead of onNext()/onError() we could have a single method which takes a Result Monad. ARC memory management might require Swift specific solutions too. 
> 
> Also on the mindset: Often I see my Android colleagues using Observables to wait for the completion of asynchronous requests. But I think these control flow scenarios are better handled by async/await instead. 
> 
> Reactive should be used when a component (class / actor) wants to make an unsolicited 'upcall'. As such it is firstly a modern variant of KVO/NotificatonCenter/Delegates/target-action etc. with the additional ability to transform / combine / schedule signals on the way from the signal producers to the signal consumers (signal stream processing).
> 
> As KVO/Delegates probably won't work correctly for Actors (because of execution context discrepancy), a reactive replacement working well with Actors is definitely needed.

i only had a little bit of rx experience but this one made me curious : why would reactive programming be a requirement for "one to one, at most once , best effort message delivery" between actors ? ( which iirc should be the only guarantee for actor to actor communication).
Rx is a very broad and generic abstraction for asynchronous communications, which brings its own share of novel issues ( at least judging by my personnal experience and the horror stories of people around me), whereas actors aim at being the most simple and straightforward way to handle concurrency and state, by acknowledging where the states should live and mutate and which shortcomings in the communication between actors have to be expected.





> 
> It would be great if a Swift reactive library would allow us to  design ViewModels (cf MVVM) as Actors and support 2 way bindings to the UI. 
> 
> Cheers 
> Marc 
> 
> 
> 
>  Ursprüngliche Nachricht  
> Von: swift-evolution at swift.org
> Gesendet: 24. September 2017 4:36 vorm.
> An: swift-evolution at swift.org
> Antworten: mattxg at gmail.com
> Betreff: Re: [swift-evolution] Standard ReactiveSteam definitions for Swift
> 
> Some thoughts as a programmer who has written an atypical reactive programming library...
> 
> You're providing protocols that strongly imply ReactiveX semantics.
> 
> Some libraries (like my own CwlSignal) look a little like ReactiveX (in that CwlSignal implements all of the ReactiveX operators) but have some quite different semantics during graph construction and during other lifecycle events. For example, CwlSignal doesn't have public Subscriber concept (responsibilities are split between the private `SignalHandler` and the `SignalSender` interface) and while the core `Signal` class is a Publisher-like concept, it is single-use which would make it a very weird implementation of this `Publisher` protocol.
> 
> These differences can make protocols for interoperability a bit of a loaded shotgun. Joining two arbitrary libraries together is likely to cause problems when the libraries have different expectations.
> 
> In some respects, it would be better to have a single, standard, concrete implementation of a class that takes an event stream input and emits an event stream. This is sometimes called a PublishSubject. A generalized PublishSubject could act as the glue between different libraries on the input and output sides. That way, the semantics of the interoperability point are fixed and each library need only ensure they support the interoperability point, rather than the semantics of every other library that could be on the other side of a protocol.
> 
> To me, I feel like this would best be implemented as part of Actor model concurrency – taking inputs and emitting outputs is fundamentally what Actors *do*.
> 
> As for naming... I would *not* recommend using `Flow` it is far too generic, has been used in very different contexts and doesn't match terminology in the field. It's fine for a library to break with common terminology for its own purposes but an interoperability interface must use the established terminology. `Publisher` and `Subscriber` are fairly clear in context but can mean very different things *outside* of reactive programming. `Observable` and `Observer` are clearer but again, the `Observer` pattern in general programming is not the same as a reactive programming `Observer` so putting it in the Swift standard library would annoy some people. On an aesthetic note, I've always found `Observer` and `Observable` difficult to read – they are similar enough that I confuse inputs and outputs when I'm tired. This is one of the reasons these terms do not appear in my library.
> 
> My personal vote is that this topic simply can't be addressed by the standard library at this point. This is something where interoperability with Swift's Actor Model should be a primary concern and until it's done, any action now is only likely to be a headache later.
> 
> Cheers,
> Matt Gallagher.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution