My apologies, I've seen three use cases. The third use case being the ability to send progress notifications.
Sent from Windows Mail From: Ron Buckton Sent: Monday, May 27, 2013 12:47 PM To: Andreas Rossberg, Tom Van Cutsem Cc: Mark S. Miller, Brendan Eich, es-discuss 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 <[email protected]<mailto:[email protected]>> On 27 May 2013 15:30, Tom Van Cutsem <[email protected]<mailto:[email protected]>> 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
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
