When the only tool you have is subclassing, all extensions look like....
Mark S. Miller
erights at google.com
Tue Jun 9 16:56:58 UTC 2015
On Tue, Jun 9, 2015 at 9:35 AM, C. Scott Ananian <ecmascript at cscott.net>
> 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
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.
> On Tue, Jun 9, 2015 at 12:13 PM, Mark S. Miller <erights at google.com>
>> 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 <
>> and implemented at <
>> 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>
>>> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss