Standard ReactiveSteam definitions for Swift

In Java 9 they have added standard definitions for Reactive Streams, the
`Flow` class, so that third party libraries, like Akka, can interoperate.
Note they haven't added an implementation of Reactive Streams, just the
type definitions.

A starting point for adding similar to Swift could be:

This would be the Swift equivalent of the Java Flow class in that it
provides definitions but not implementations, which will enable third party
libraries and eventually whatever goes into Swift at language and library
levels to interoperate.

Whereas adding concurrency in general will be a long process, these
definitions could be added now.

Thoughts?

  -- Howard.

PS You can find out about Reactive Steams and the standardization of them
at http://www.reactive-streams.org/

+1

Btw, I kinda like the `Flow` name (or even `Observable`). Don’t like `ReactiveStream` at all.

-g.

···

On 19 Sep 2017, at 3:59 AM, Howard Lovatt via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

http://www.reactive-streams.org/

Copied from the corresponding Github issue, I would like to hear opinions from the broader community on this:

I am wondering if the correct 'translation' to Swift of:

onNext()
onError()

is really:

on(next:)
on(error:)

maybe something closer to Foundation's naming conventions would be:

didReceive(next:) or didReceive(value:)
didReceive(error:)

-g.

Copied from the corresponding Github issue, I would like to hear opinions from the broader community on this:

I am wondering if the correct 'translation' to Swift of:

onNext()
onError()

is really:

on(next:)
on(error:)

I’ve played around with reactive streams, and one of the main issues with this naming convention is that it really confuses the compiler when you try to use trailing closure syntax:

aStream.on { nextOrError in

}

The compiler has a really hard time inferring what the type of nextOrError is without explicitly typing the parameter or not using trailing closure syntax.

Using .onNext { … } or .onError { … } bypasses this problem entirely.

Dave

···

On Sep 23, 2017, at 1:24 AM, Georgios Moschovitis via swift-evolution <swift-evolution@swift.org> wrote:

maybe something closer to Foundation's naming conventions would be:

didReceive(next:) or didReceive(value:)
didReceive(error:)

-g.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

I stuck with the standard names that other languages use. In Java they
enclosed the standard protocol/interface names Process, Publisher,
Subscriber, along with a useful constant inside a namespace Flow, so you
say Flow.Publisher for example.

The same could be done for Swift, it is a matter for the Swift community to
decide.

You could also change the names of the protocols, but that would make
standard documents and code from other languages hard to follow.

···

On Fri, 22 Sep 2017 at 3:11 am, Georgios Moschovitis < george.moschovitis@icloud.com> wrote:

+1

Btw, I kinda like the `Flow` name (or even `Observable`). Don’t like
`ReactiveStream` at all.

-g.

On 19 Sep 2017, at 3:59 AM, Howard Lovatt via swift-evolution < > swift-evolution@swift.org> wrote:

http://www.reactive-streams.org/

--

-- Howard.

Not quite understanding your concern, perhaps you could elaborate. In
particular:

  1. The names I proposed were on(next:) and on(error:) so there is no
confusion since next and error are still part of the name. I just moved
them inside the brackets like commonly done in Swift.

  2. Neither on(next:) nor on(error:) accept a closure, they take values.

  3. You don’t manually call either on(next:) or on(error:), the only
method you interact with is subscribe. Which in my library I have
overloaded with ~~> so that you don’t call methods at all on reactive
stream objects. See README for
https://github.com/hlovatt/Concurrency-Utilities\.

Hello World using this library is:

let helloWorldPublisher = ForEachPublisher(sequence: "Hello, world!".characters)
let helloWorldSubscriber = ReduceSubscriberFuture(into: "") { (result:
inout String, next: Character) in
    result.append(next)
}
var helloWorldResult = "Failed!" // Default value for failure, timeout, etc.
helloWorldPublisher ~~> helloWorldSubscriber ~~>? helloWorldResult

Note how the arguments to ForEachProducer and ReduceSubscriberFuture mimic
those to similarly named methods in Swifts Sequence protocol, how Subscriber
's ~~> is evocative of the process that is occurring, and how Future's
~~>? looks
natural and controls execution and error reporting. Fire is another part of
the library, see readme.

···

On Sun, 24 Sep 2017 at 12:25 am, Dave DeLong via swift-evolution < swift-evolution@swift.org> wrote:

On Sep 23, 2017, at 1:24 AM, Georgios Moschovitis via swift-evolution < > swift-evolution@swift.org> wrote:

Copied from the corresponding Github issue, I would like to hear opinions
from the broader community on this:

I am wondering if the correct 'translation' to Swift of:

onNext()
onError()

is really:

on(next:)
on(error:)

I’ve played around with reactive streams, and one of the main issues with
this naming convention is that it really confuses the compiler when you try
to use trailing closure syntax:

aStream.on { nextOrError in

}

The compiler has a really hard time inferring what the type of nextOrError
is without explicitly typing the parameter or not using trailing closure
syntax.

Using .onNext { … } or .onError { … } bypasses this problem entirely.

Dave

maybe something closer to Foundation's naming conventions would be:

didReceive(next:) or didReceive(value:)
didReceive(error:)

-g.

_______________________________________________
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.