[swift-evolution] Standard ReactiveSteam definitions for Swift

[Howard Lovatt]

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 at swift.org> wrote:

>
>
> > 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
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
-- Howard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170926/6b23b493/attachment.html>