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