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

-------------- 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