Sanity check on return() and throw() about proposal-observable

[zenparsing]

%SubscriptionObserverPrototype%.return(v) returns { value: undefined, done: true } if the un-normalized sink has no return method. But { value: v, done: true } seems more correct, based on how generators behave?

How so? If I have a generator that doesn't have a return statement (and no weird finally's), then invoking "return" will always give me { value: undefined, done: true } regardless of the arguments. (Perhaps that's not a good analogy, though.)

Both generators and %SubscriptionObserverPrototype% allow multiple calls to return() or throw(), which after the first do nothing but the default action---i.e. they don't affect the state in any way. Did I get this right?

That's right.

For both generators and %SubscriptionObserverPrototype%, calling throw() will then cause next() to always return { value: undefined, done: true }. This is surprising to me---I would have expected it to re-throw the error?

I'm not sure what the rationale was for that behavior on the generator side, but I don't think it causes any problems for Observable. Do you?

I am also curious how the cancellation function maps to generators. It seems like a pretty ad-hoc addition to me and I can't really make the mapping back.

The cancellation function (the "unsubscriber") acts similarly to a finally clause within a generator function. The idea is that the generator or observable needs a way to release any held resources, regardless of how the sequence is terminated (naturally or prematurely). For generators we have the finally clause. For observables we have the unsubscriber function.

See #14 for an open question regarding the unsubscriber function. Any input is appreciated!

[domenic]

How so? If I have a generator that doesn't have a return statement (and no weird finally's), then invoking "return" will always give me { value: undefined, done: true } regardless of the arguments.

I was thinking https://people.mozilla.org/~jorendorff/es6-draft.html#sec-generatorresumeabrupt step 4.a.i.

I'm not sure what the rationale was for that behavior on the generator side, but I don't think it causes any problems for Observable. Do you?

Hmm, well for iterators it means you can't read the failure value out of the iterator. Not sure how it plays out for observers.

The cancellation function (the "unsubscriber") acts similarly to a finally clause within a generator function.

Makes some sense, but not entirely.

Under the paradigm that new Observable(fn) creates a function-class that roughly encapsulates calling fn(sink), it sounds like the actual behavior roughly-encapsulated by [Symbol.observer]() ends up being something like

let returnValue;
try {
  returnValue = fn(sink);
} async finally {
  returnValue();
}

?

Maybe a better model is new Observable(tryFunction, finallyFunction) which encapsulates the behavior

try {
  tryFunction(sink);
} async finally {
  finallyFunction();
}

Of course that raises the question: why don't we have a catchFunction? And now we're basically back to cancelable promises (which also have a .finally method with similar semantics).

[zenparsing]

I was thinking https://people.mozilla.org/~jorendorff/es6-draft.html#sec-generatorresumeabrupt step 4.a.i.

Ah, you're right. I'll make that change.

[zenparsing]

Maybe a better model is new Observable(tryFunction, finallyFunction)

Often, the subscriber function will create declare local variables that the cleanup function needs to access (e.g. the "listen" example on the README). For that reason it's convenient to define the cleanup function within the scope of the subscriber function. And since you don't want the cleanup function to run until after the subscriber function completes, returning it is both ergonomic and makes sense.

[domenic]

Sure, but that's not really how scoping works for try/finally.

[zenparsing]

Closing for cleanup