When the only tool you have is subclassing, all extensions look like....

C. Scott Ananian ecmascript at cscott.net
Tue Jun 9 16:35:59 UTC 2015

Promise subclassing is super useful.  `prfun` uses it extensively: first to
override the global `Promise` to avoid polluting the global namespace, and
then secondly to implement features like `Promise#bind`.  I've also used it
experimentally to implement "functional" promises (with a `Promise#chain`
method) on top of ES6 Promises.

I actually had a paragraph like this in my earlier response (on the other
thread) and deleted it, since it seemed off-topic there.  But suffice it to
say I've already used the subclass extension mechanism for Promises in a
number of ways which are impossible with the more-limited and ad hoc
"makeRemote" mechanism.  And you say that you can implement pipelining on
top of subclassing.  So subclassing seems more general to me...

What's the specific use case which you can't make work with a Promise

On Tue, Jun 9, 2015 at 12:13 PM, Mark S. Miller <erights at google.com> wrote:

> My larger theme here is that I think promise subclassing is way overrated.
> OO programmers tend to treat subclassing according to the "everything is a
> hammer" rule. Promises do need an extension point, such as the old makeFar
> and makeRemote proposals explained at <
> http://wiki.ecmascript.org/doku.php?id=strawman:concurrency#fundamental_static_q_methods>
> and implemented at <
> https://github.com/tvcutsem/es-lab/blob/master/src/ses/makeQ.js#L476>, in
> order to enable promise pipelining.
> However, since we have (mal)invested so much effort into providing
> subclassing as the promise extension mechanism, when rebuilding promise
> pipelining on ES6 promises, we will use the subclassing extension point
> instead, even though it is less modular. At least pipelining is a case
> which does require propagation, so the ES6 subclassing mechanisms should
> work for these. (With some caveats to be explained in later email.)
> On Tue, Jun 9, 2015 at 9:00 AM, Mark S. Miller <erights at google.com> wrote:
>> I know I'm being picky here, but if timeout-ness is not intended to
>> propagate, which seems sensible, then why would I ever want to invent a
>> TimeoutPromise subclass rather than using a combinator like delay or race
>> on a plain Promise?
> --
>     Cheers,
>     --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150609/f580b223/attachment.html>

More information about the es-discuss mailing list