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

Mark Miller erights at gmail.com
Tue Jun 9 19:45:14 UTC 2015

I don't understand your answer. p and r are plain promises. They must be
because they exist before q does. q is the first remote promise in this
scenario. How does resolving r to q leave r unsettled but give q access to
the messages buffered (and to be buffered) in r?

I think the answer must involve the to-be-defined behavior of .get, .put,
.post, .delete, and .where. These should be in bed with the implementation
of the built-in promise resolve, so that when r is resolved to q, if q is a
genuine promise (whatever that means in this new world), then r should
migrate its messages there.

However, to implement this on ES6 without monkey patching would require
intervening in the internal resolving of r while still leaving r unsettled.
If q intervenes by overriding .then, this does give it control during the
resolution. But it doesn't give it access to r with which the buffered
messages is associated.

I don't get it.

On Tue, Jun 9, 2015 at 11:20 AM, C. Scott Ananian <ecmascript at cscott.net>

> On Tue, Jun 9, 2015 at 1:43 PM, Mark S. Miller <erights at google.com> wrote:
>> On Tue, Jun 9, 2015 at 10:38 AM, C. Scott Ananian <ecmascript at cscott.net>
>>  wrote:
>>> I think that Promise pipelining works just fine -- you just have to
>>> implement it inside Promise#get, Promise#put, etc.
>>> ```
>>> // This is already in prfun
>>> Promise.get = function(fieldname) { return this.then(function(o) {
>>> return o[fieldname]; }); };
>>> // This comes with your RPC mechanism
>>> class RemoteObjectPromise extends Promise {
>>>   this(args...) {
>>>     let res, rej;
>>     if (typeof(args[0]) !== 'string') throw new TypeError("Not a remote
>>> reference!");
>>     super((a,b)=>{res=a;rej=b;});
>>>     this.handle = gensym();
>>>     // first argument to rpcCall is "destination" of the operation
>>>     rpcCall(this.handle, ...args).then( v => res(v), e => rej(v) );
>>>   },
>>   get(fieldname) {
>>    // note that this.handle is a name for the remote object, it is not a
>>> resolved value.
>>>    // as such, this method doesn't have to wait until the remote object
>>> corresponding to
>>>    // this.handle is resolved
>>>    return new RemoteObjectPromise('GET', this.handle, fieldname);
>>   }
>> }
>>> ```
>> What about the interaction between q and r in .then, that I mentioned in
>> my previous email? That's the reason I changed my mind and now think we
>> need an extension mechanism besides subclassing in order to make pipelining
>> work. Note: it needs to work even if p is a plain promise. It is only q
>> that knows that the scenario is special.
> Oh, right, I forgot:
> ```
> RemoteObjectPromise[Symbol.species] = Promise;
> ```
> That takes care of `then()`...
> And provides another nice use case for species.
> What would you expect `RemoteObjectPromise.all()` to do in this case?
> Probably `RemoteObjectPromise.prototype.all()` makes more sense -- if you
> have a remote reference to a (promised) array, you can pipeline the wait
> for all the elements in the array, without having to do all the waits on
> the client side.
> But in this case `RemoteObjectPromise.prototype.all()` is probably
> special-cased (and ignores species):
> ```
> RemoteObjectPromise.prototype.all = function() {
>   return new RemoteObjectPromise('ALL', this.handle);
> };
> // And this is what I claim that `Promise.all` should also be:
> RemoteObjectPromise.all = function(x) { return this.resolve(x).all(); };
> ```
> Note that, given the definition above (I've tweaked it slightly),
> `RemoteObjectPromise.resolve(x)` throws TypeError if `x` is not already a
> remote object reference.  You could tweak it to perform a migration or some
> such if you preferred.
>   --scott
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

Text by me above is hereby placed in the public domain

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150609/e60863a9/attachment-0001.html>

More information about the es-discuss mailing list