> Am 27.09.2017 um 16:37 schrieb Marc Schlichte via swift-evolution > <[email protected]>: > > I also think that actors and signals have to be designed together: > > E.g. how would you subscribe in your actor to a signal defined in another > actor so that it is thread safe. > > I could imagine that the signals used in actors are actors themselves ( maybe > sharing the execution context of their containing actor if this is deemed to > be inefficient - which should not be the case)
How actor based signals might work can be seen in my simple actor playground: https://github.com/frameworklabs/actress <https://github.com/frameworklabs/actress> With future syntax support, this might look like: ``` actor class Sender { let signal = Signal<Int>() actor func start() { signal.emit(21) } } actor class Receiver { init(sender: Sender) { let conn1 = await sender.map { $0 * 2 }.connect(actor: self, method: Receiver.receive) disposeBag.add(conn1) // or with `actor closures`: let conn2 = await sender.map { $0 * 2 }.connect(actor: self) { [unowned self] value in print("me \(self) got \(value)“) } disposeBag.add(conn2) } actor func receive(_ value: Int) { print("me \(self) got \(value)“) } } ``` > > Cheers > Marc > Von: [email protected] > Gesendet: 26. September 2017 9:04 vorm. > An: [email protected]; [email protected] > Antworten: [email protected] > Betreff: Re: [swift-evolution] Standard ReactiveSteam definitions for Swift > > Comments in-line below. > > > On Sun, 24 Sep 2017 at 12:36 pm, Matt Gallagher via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > Some thoughts as a programmer who has written an atypical reactive > programming library... > > You're providing protocols that strongly imply ReactiveX semantics. > > ReactiveX can be built upon Reactive Streams, e.g. RxJava 2.0., but the idea > of Reactive Streams is that the protocol is so low level you don’t interact > directly with them. They seem compatible with many different styles including > actors, e.g. Akka (the Akka people destined Reactive Streams I think). > Reactive Streams are very actor like with one way communication links that > transfer a copy of single items/errors or no items/error (pure messages). > > > 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. > > Nothing in the Reactive Stream specification to prevent single use > Publishers, Subscribers, or Processors. The Reactive Stream specification > only talks about the communication and error reporting. As long as your > library has the concept of a subscription of some form you can probably write > translators to the 3 protocols. > > > 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. > > Seems to work OK in the Java world, people use Akka and RxJava together. > > > 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. > > This is what Reactive Streams are. They just tell you how to hook things up, > how to ask for items, how to report errors, and how to finish with a > connection. They do not dictate the semantics at the other end. For example > your translator could throw fatal exception on an error if your library > didn’t report errors or wrap the error in a Result type if it handled error > in a functional way. > > > 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 I have said they are very actor like and I think it was the Akka people > who came up with the specification therefore I am not sure you are locking > anything out. If the Swift actor model can’t interact with something as > simple as Reactive Streams it will not interact with anything other than > other Swift Actors, which would be very limiting. For example you would > expect the Swift actors to interact with GCD, perhaps via suitable wrappers. > > > 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. > > I would prefer to move forward more quickly, I don’t think there is much risk > since the specification is so low level and flexible. The whitpaper from > Chris Lattner also mentions that it would be desirable for any Actor system > in Swift to be compatible with Reactive Streams, so why not start now. > > > > Cheers, > Matt Gallagher. > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > -- > -- Howard. > _______________________________________________ > 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
