Are there a fixed number of use cases for promise subclasses? I've seen discussions about two possibilities referred to on this list, specifically a lazy-promise and a cancellable promise. I wonder if these two capabilities should instead be part of the Promise/Future API and not have subclasses promises. High-order operations like Q.all/Future.every will cause the subclass to be lost to the resulting operation.

I do agree with the earlier discussion that adding a cancel method to a promise can expose too much to the consumer, allowing multiple consumers of the same promise the ability to cancel the root. I have been experimenting [1] with supplying a cancellation signal from outside the promise that can be provided to the various API's (as an optional argument to the constructor and to then/done) to allow for cancellation but respect the separation of responsibilities between a promise and its creator. This makes cancellation optional, but fully baked into the API, as well as allowing the promise to fully cooperate with cancellation internally.

In a similar way we could enable lazy initialization of the promise via an argument to the constructor. Are there other use cases for promise subclasses?

Not subclassing promise doesn't prevent it from being a first-class object, just as how today you can't subclass Function, yet functions are first class.

Ron

[1] http://github.com/rbuckton/promisejs

Note: this is roughly based off of the DOM Futures spec with some non-spec additions, and performs auto-lift and single unwrap as discussed in an earlier thread.

Sent from Windows Mail

From: Tom Van Cutsem
Sent: ?Monday?, ?May? ?27?, ?2013 ?8?:?09? ?AM
To: Andreas Rossberg
Cc: Mark S. Miller, Brendan Eich, es-discuss

2013/5/27 Andreas Rossberg <rossberg at google.com<mailto:rossberg at google.com>>
On 27 May 2013 15:30, Tom Van Cutsem <tomvc.be at gmail.com<mailto:tomvc.be at gmail.com>> wr
> What the discussion at last week's TC39 meeting clarified for me is the
> following:
>
> - Promises are primarily a control-flow abstraction.
> - Sometimes, they are also used as a data-abstraction (i.e. as a container
> in their own right, wrapping an arbitrary payload).
> - All of the subtle problems discussed in these threads only start to arise
> when these two use cases of promises are being mixed, e.g. a
> promise-as-data-container being mistaken for a
> promise-as-control-abstraction. This rarely happens in application code, but
> may happen in generic library code.

Well, the gist of higher-order languages is that control flow
abstractions _are_ data. For example, that's the defining
characteristics of first-class functions. And while most functions
won't be used in a first-class manner (and most programmers probably
don't think about them that way), the ability to do so gives great
power -- as JavaScript demonstrates very well.

Futures/promises are an abstraction for first-class synchronisation.
For the same reason you sometimes want to store or pass back & forth
functions, you will sometimes want to store or pass promises. Not
being able to combine those abstractions freely and transparently
would arbitrarily limit their power, and practically demote promises
to second-class status.

I agree with everything you said, but I fail to see why Q-style promises would become second-class. I have enjoyed writing and working with higher-order combinators like Q.all, which creates a promise for an array of promises. Your text above would seem to imply that writing or using such combinators would somehow be hampered by the recursive flattening, but I have never bumped into this issue. I think the reason is that when promises are used as data in combinators like Q.all, the composite abstraction as a whole remains a control-flow abstraction.

Cheers,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130527/c1d7ad49/attachment.html>

Are there a fixed number of use cases for promise subclasses? I've seen discussions about two possibilities referred to on this list, specifically a lazy-promise and a cancellable promise. I wonder if these two capabilities should instead be part of the Promise/Future API and not have subclasses promises. High-order operations like Q.all/Future.every will cause the subclass to be lost to the resulting operation.

I do agree with the earlier discussion that adding a cancel method to a promise can expose too much to the consumer, allowing multiple consumers of the same promise the ability to cancel the root. I have been experimenting [1] with supplying a cancellation signal from outside the promise that can be provided to the various API's (as an optional argument to the constructor and to then/done) to allow for cancellation but respect the separation of responsibilities between a promise and its creator. This makes cancellation optional, but fully baked into the API, as well as allowing the promise to fully cooperate with cancellation internally.

In a similar way we could enable lazy initialization of the promise via an argument to the constructor. Are there other use cases for promise subclasses?

Not subclassing promise doesn't prevent it from being a first-class object, just as how today you can't subclass Function, yet functions are first class.

[1]: http://github.com/rbuckton/promisejs

Note: this is roughly based off of the DOM Futures spec with some non-spec additions, and performs auto-lift and single unwrap as discussed in an earlier thread.