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

Mark S. Miller erights at google.com
Tue Jun 9 16:53:11 UTC 2015


On Tue, Jun 9, 2015 at 9:13 AM, 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.)
>

OMG, I had this *exactly* backwards! In

const r = p.then(() => q);

remoteness must not an cannot propagate from p to r, since the callback is
necessarily local. Remoteness propagates from p to r *only* for .get, .put,
.post, .delete, and .there -- none of which yet exist in the std.

Worse, the std does not provide for interaction between q and r that would
enable promise pipelining when q is remote. What is needed is that, when q
is an unsettled remote promise, resolving r to q leaves r unsettled but
gives all message pending in r, both present and future, to q so q can
forward them to the remote machine.

Sigh. Even though ES6 promises stayed fairly close to E promises (where
makeFar and makeRemote originated), getting from ES6 promises to remote
promises with promise pipelining is going to be more work than I thought.



>
>
>
> 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/b08d3297/attachment.html>


More information about the es-discuss mailing list