Nothing to stop you having Observables linked to a Reactive Stream library, the RxJava 2 library has Observables and is built on top of Reactive Streams.
On Mon, 25 Sep 2017 at 5:15 am, Marc Schlichte via swift-evolution < [email protected]> wrote: > 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. > > 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: [email protected] > Gesendet: 24. September 2017 4:36 vorm. > An: [email protected] > Antworten: [email protected] > 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > -- -- Howard.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
