<div dir="ltr">I think that Promise pipelining works just fine -- you just have to implement it inside Promise#get, Promise#put, etc.<div>```</div><div>// This is already in prfun</div><div>Promise.get = function(fieldname) { return this.then(function(o) { return o[fieldname]; }); };</div><div>// This comes with your RPC mechanism</div><div>RemoteObjectPromise.get = function(fieldname) {</div><div>   // note that this.handle is a name for the remote object, it is not a resolved value.</div><div>   // as such, this method doesn't have to wait until the remote object corresponding to</div><div>   // this.handle is resolved</div><div>   return new RemoteObjectPromise('GET', this.handle, fieldname);<br></div><div>};</div><div>class RemoteObjectPromise extends Promise {</div><div>  this(args...) {<br></div><div>    let res, rej;</div><div>    super((a,b)=>{res=a;rej=b;});</div><div>    this.handle = gensym();</div><div>    // first argument is "destination" of the operation</div><div>    rpcCall(this.handle, ...args).then( v => res(v), e => rej(v) );</div><div>  }</div><div>}</div><div>```</div><div>  --scott</div>​</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 9, 2015 at 12:56 PM, Mark S. Miller <span dir="ltr"><<a href="mailto:erights@google.com" target="_blank">erights@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Tue, Jun 9, 2015 at 9:35 AM, C. Scott Ananian <span dir="ltr"><<a href="mailto:ecmascript@cscott.net" target="_blank">ecmascript@cscott.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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...</div><div><br></div><div>What's the specific use case which you can't make work with a Promise subclass?</div></div></blockquote><div><br></div><div><br></div></span><div>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.</div><span class=""><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span><font color="#888888"><div>  --scott</div><div><br></div></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 9, 2015 at 12:13 PM, Mark S. Miller <span dir="ltr"><<a href="mailto:erights@google.com" target="_blank">erights@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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 <<a href="http://wiki.ecmascript.org/doku.php?id=strawman:concurrency#fundamental_static_q_methods" target="_blank">http://wiki.ecmascript.org/doku.php?id=strawman:concurrency#fundamental_static_q_methods</a>> and implemented at <<a href="https://github.com/tvcutsem/es-lab/blob/master/src/ses/makeQ.js#L476" target="_blank">https://github.com/tvcutsem/es-lab/blob/master/src/ses/makeQ.js#L476</a>>, in order to enable promise pipelining.<div><br></div><div>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.)</div><div><br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 9, 2015 at 9:00 AM, Mark S. Miller <span dir="ltr"><<a href="mailto:erights@google.com" target="_blank">erights@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">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?
</div><div class="gmail_extra"><br></div></div><span><font color="#888888">
</font></span></blockquote></div><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div>    Cheers,<br>    --MarkM</div><div><br></div>
</font></span></div></div>
</blockquote></div><br></div>
</div></div></blockquote></span></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div>    Cheers,<br>    --MarkM</div>
</font></span></div></div>
</blockquote></div><br></div>