You wouldn’t normally use Reactive Streams directly, think of them as the Babel Fish (hitch hikers) of Streams/actors. If Swift actors talked Reactive Stream and so did some other library, Akka, RxSwift, etc., then the two could talk to each other. Which would be a big advantage on large projects with multiple code bases.
On Mon, 25 Sep 2017 at 8:38 am, Benjamin Garrigues via swift-evolution < swift-evolution@swift.org> wrote: > > > > Le 24 sept. 2017 à 21:15, Marc Schlichte via swift-evolution < > swift-evolution@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@swift.org > > Gesendet: 24. September 2017 4:36 vorm. > > An: swift-evolution@swift.org > > Antworten: mat...@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@swift.org > > https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > > swift-evolution mailing list > > swift-evolution@swift.org > > https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > -- -- Howard.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
