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

Mark S. Miller erights at google.com
Tue Jun 9 17:43:20 UTC 2015


What about the interaction between q and r in .then, that I mentioned in my
previous email? That's the reason I changed my mind and now think we need
an extension mechanism besides subclassing in order to make pipelining
work. Note: it needs to work even if p is a plain promise. It is only q
that knows that the scenario is special.



On Tue, Jun 9, 2015 at 10:38 AM, C. Scott Ananian <ecmascript at cscott.net>
wrote:

> I think that Promise pipelining works just fine -- you just have to
> implement it inside Promise#get, Promise#put, etc.
> ```
> // This is already in prfun
> Promise.get = function(fieldname) { return this.then(function(o) { return
> o[fieldname]; }); };
> // This comes with your RPC mechanism
> RemoteObjectPromise.get = function(fieldname) {
>    // note that this.handle is a name for the remote object, it is not a
> resolved value.
>    // as such, this method doesn't have to wait until the remote object
> corresponding to
>    // this.handle is resolved
>    return new RemoteObjectPromise('GET', this.handle, fieldname);
> };
> class RemoteObjectPromise extends Promise {
>   this(args...) {
>     let res, rej;
>     super((a,b)=>{res=a;rej=b;});
>     this.handle = gensym();
>     // first argument is "destination" of the operation
>     rpcCall(this.handle, ...args).then( v => res(v), e => rej(v) );
>   }
> }
> ```
>   --scott
>>
> On Tue, Jun 9, 2015 at 12:56 PM, Mark S. Miller <erights at google.com>
> wrote:
>
>>
>>
>> On Tue, Jun 9, 2015 at 9:35 AM, C. Scott Ananian <ecmascript at 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 <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
>>>>
>>>>
>>>
>>
>>
>> --
>>     Cheers,
>>     --MarkM
>>
>
>


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150609/92a05de5/attachment.html>


More information about the es-discuss mailing list