[swift-evolution] Standard ReactiveSteam definitions for Swift

[Howard Lovatt]

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

>
> On Sep 23, 2017, at 1:24 AM, Georgios Moschovitis via swift-evolution <
> swift-evolution at 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 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/a2039e9c/attachment.html>