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 <[email protected]> wrote:
>
>
> On Tue, Jun 9, 2015 at 9:35 AM, C. Scott Ananian <[email protected]>
> 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 <[email protected]>
>> 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 <[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
>>>
>>>
>>
>
>
> --
> Cheers,
> --MarkM
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
