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 <ecmascr...@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 <erig...@google.com>
> wrote:
>
>>
>>
>> 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
>>
>
>
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
