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 <
> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss