Motivate subscribe vs forEach

[benjamingr]

Hey, can we get an example motivating why both subscribe and forEach are needed?

[jhusain]

Async/Await Observation.

async function getPriceHigh(stock) {
    let delta,
        high = Number.MIN_VALUE;

    let socket = new WebSocket(“/dailyPrices/" + stock);
    await Observable.from(socket).forEach(price => {
          if (price > high) {
          high = price;
      }
    });

    return high;
}

[zenparsing]

An interesting question on the table is if we could merge subscribe and forEach by making the subscription object a promise (or thenable).

So in the example, you could just replace the forEach with subscribe and it would work fine:

await Observable.from(socket).subscribe(price => {
  if (price > high) {
    high = price;
  }
});

It would be a nice simplification, all other things being equal.

[benjamingr]

Yes, this definitely seems like a good idea to merge the two - there is nothing preventing subscribe from being a thenable/promise.

[jhusain]

Not sure why this is attractive. Promise essentially duplicates semantics of return() and throw() callbacks passed to subscribe. Would also like to understand performance implications.

[jhusain]

what a happens if I do this:

try {
await obs.subscribe({ throw(e) { /* error handling / }, return(v) { / error handling */ } })
}
catch(e) {
// other error handling
}

Gives the developer of the opportunity to duplicate error handling logic two places. furthermore the Observer callbacks may or may not be executed synchronously, whereas the promise error will only be executed asynchronously. This seems like a big foot gun to me.

[jhusain]

Big mistake to build observable with promises. There is too much semantic overlap, coupled with impedance mismatch. adapting between them is unambiguous.

[domenic]

what a happens if I do this:

Yes, agreed. It seems this proposal could be greatly simplified by removing subscribe and [Symbol.observe] in favor of forEach---at least, assuming we get cancelable promises. With that assumption there's no loss in power and a great increase in interoperability and compositionality.

[zenparsing]

I agree as well and withdraw the suggestion : )

[jhusain]

Withdrawing Symbol.observe and subscribe on the assumption that Cancellable
Promises arrive would couple these two proposals. Seems ill-advised. However having
forEach around means that we could simplify the proposal at a later stage
if Cancellable Promises gains traction.

On Tue, Jun 2, 2015 at 1:35 PM, zenparsing notifications@github.com wrote:

I agree as well and withdraw the suggestion : )

—
Reply to this email directly or view it on GitHub
#20 (comment)
.

[domenic]

Yeah, agreed. I like the plan of keeping both for now in the hope of removing one if we get cancellable promises shipping soon. Nice.

I still think having both [Symbol.observe] and subscribe is a bit redundant but I haven't dug into it much and we can move that to another bug.

[zenparsing]

Any objections to closing this one?

[benjamingr]

Resolution sounds good to me 👍

[benjamingr]

Re-reading this, why would subscribe returning a thenable mean we'd have to have cancellable promises in order for observers to be cancellable?

Can't subscribe return a thenable/Promise which is also a subscription and we get to have the best of both worlds?

[benlesh]

why would subscribe returning a thenable mean we'd have to have cancellable promises in order for observers to be cancellable?

@benjamingr because subscribe should return a mechanism for notifying the producer to stop pushing values (unsubscription/cancellation)

[benjamingr]

Yes, but why not both? Why can't it have then and unsubscribe

[benlesh]

Because at that point someone will argue that it should be a cancelable promise, which marries the two proposals. I don't think cancelable promises are a great idea, personally.

[benjamingr]

Because at that point someone will argue that it should be a cancelable promise, which marries the two proposals. I don't think cancelable promises are a great idea, personally.

I agree (with not marrying the proposals). What I'm asking is - why can't we return a promise which is a subscription that can be disposed?

That way if in the future cancellable promises make it we'll also make the returned promise cancellable to benefit from facilities but we get a subscription with a then and an unsubscribe which means we can dispose it and await it. Wouldn't that be worth it?

[benlesh]

@benjamingr at this point I honestly think the subscribe function should return a generator type that also has the dispose method that is sorely missing from Generator. If there were a proposal to marry it to, it would be the proposal of putting a dispose method on Generator that only called the generator's finally block. cc/@jhusain

[benjamingr]

The generator subscription proposal is starting to grow on me.

Since it is now a sequence, I wonder if await* can be used instead of await, this also has the nice property of showing that it's in fact a sequence that's being awaited.

It would require next on the returned subscription, that would have to return promises somehow in order to work with await* though. Do you think a new thread should be opened?