[swift-evolution] Standard ReactiveSteam definitions for Swift

[Howard Lovatt]

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 <
swift-evolution at swift.org> 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: 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
>
-- 
-- Howard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170926/538bbcb4/attachment.html>