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

C. Scott Ananian ecmascript at cscott.net
Tue Jun 9 17:38:29 UTC 2015


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150609/b87e3e11/attachment-0001.html>


More information about the es-discuss mailing list