On Tue, Jun 9, 2015 at 9:35 AM, C. Scott Ananian <ecmascr...@cscott.net> wrote:
> 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 > subclass? > Funny enough, I replied before I saw this. The use case I can't make work using only subclassing as an extension mechanism is promise pipelining. > --scott > > > On Tue, Jun 9, 2015 at 12:13 PM, Mark S. Miller <erig...@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 <erig...@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 >> >> > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
