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 <[email protected]> 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
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
