Direct proxies update

David Bruant bruant.d at gmail.com
Tue Nov 29 13:15:55 PST 2011


Le 29/11/2011 21:24, Mark S. Miller a écrit :
> On Tue, Nov 29, 2011 at 11:03 AM, David Bruant <bruant.d at gmail.com
> <mailto:bruant.d at gmail.com>> wrote:
>
>     Le 29/11/2011 19:05, Mark S. Miller a écrit :
>>     On Tue, Nov 29, 2011 at 10:01 AM, David Bruant
>>     <bruant.d at gmail.com <mailto:bruant.d at gmail.com>> wrote:
>>
>>         Le 29/11/2011 18:40, Tom Van Cutsem a écrit :
>>
>>     [...] 
>>
>>>         The general rule here is: if your code needs to handle both
>>>         local and remote values, deal with the remote/async case
>>>         only. The local case should be a subset of the remote case.
>>         Oh ok, interesting.
>>         ... but does that mean that as soon as we bring concurrency
>>         (and asynchronisity) to ECMAScript, every API manipulating
>>         objects (or potentially any remote value)
>>
>     should be design in the async style (additional callback argument
>     instead of return value)
>
>>         ?
>>
>>
>>     Hi David, could you complete your question? Thanks.
>     sorry.
>
>     I think that the answer to my question is to keep designing APIs
>     as it has been but to return a promise for the asynchronous case
>     and the API client will use the pattern Tom showed
>     ('Q(a).when(function(val){})').
>
>
> Yes. Or 'Q(a).get("foo")' or 'Q(a).send("foo", b, c)' or their
> respective sugared form 'a ! foo' or 'a ! foo(b, c)', depending on
> what you want to do with 'a'. Note that if 'a' designates a remote
> object, in 'Q(a).when(function(val){...})', 'val' will still be bound
> to a far reference which is still a form of promise whose "." access
> the promise API rather than the API of the remote target object.
> If you invoke the designated object's API simply with "!", that works
> whether 'a' is a non-promise, a promise for a local object, or a
> promise for a remote object. In all cases, the value of the infix "!"
> expression is reliably a promise.
>
>  
>
>     The Reflection API could do that (that's actually what Tom
>     suggested at some point) and a proxy reflecting a remote object
>     could also return promises.
>
>
> I don't understand.
In order to support reflection of both local and remote objects, the
Reflection API could return promises: "Reflection.has(o, 'a')" would
return a boolean if o is local or a promise to a boolean if o is remote.

For the second part, I was saying that
http://wiki.ecmascript.org/doku.php?id=harmony:proxies#an_eventual_reference_proxy
could be reimplemented and return promises instead of the setTimeout(0).
But I'm a bit confused with this example, because some things are async
(defineProperty, delete, etc.), but some others are synchronous
(getOwnPropertyNames, has, etc.).
Shouldn't everything return promises?

>  
>
>
>     Very much like Tom said about Mirror.on(obj).has, maybe that for
>     the local case, instanciating a promise for a local value could be
>     avoided.
>     What about 'Q.when(a, function(val){});' or 'When(a,
>     function(val){})'? in which a is either a promise or a local value
>     and this acts like we'd expect 'Q(a).when(function(val){})' to.
>
>
> Are you just concerned with avoiding an extra allocation, or am I
> missing some other issue here?
Avoiding an extra allocation is the only worry for this last point. Very
much like Tom worried about mirror allocation at
https://mail.mozilla.org/pipermail/es-discuss/2011-November/018734.html

Digression about memory in JS implementations:
I've been following the MemShrink effort in Firefox. Data structures
have been shrinked, fragmentation has been reduced making a better use
of memory, but I have seen much less work toward reducing the number of
allocations. This is certainly because the study of when an allocation
is required or not is usually complicated.
I don't know what the exact status of implementations is, but what
happens in current JS engines when the expression '[].forEach.call' is
met? Is the allocation of an array actually performed? Hopefully not, I
would not be surprised if it was.

Back to promises, it seems that Q(p).when(f) may become a common
programming pattern to express "if p is a local value, call f at next
turn with p as argument. If p is a promise, call f with its resolution
when resolved". If it becomes so, it means that a Q(p) will generate a
promise to throw away in the local value case.
As usual in JavaScript, static analysis won't be possible to avoid the
allocation, because Q(p) could return anything (since Q could be
overridden or come from who-knows-where).
On the other hand, if we have a functional API like 'when(p, f)', we
avoid the allocation by design and are able to express the exact same
thing.


Taken from a different perspective, if we start designing APIs which
return either a local value or a promise to a value, maybe that the
promise API should work with both (instead of having to being forced to
turn everything into a promise before using the API as it is now).
p.when is the only part of the API that would be affected, I think.


Looking through Promise methods
(http://wiki.ecmascript.org/doku.php?id=strawman:concurrency#promise_methods),
I realize that these (besides p.when and p.end) could just be replaced
by the Reflection API being adapted to work with promises.

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


More information about the es-discuss mailing list