Direct proxies update

David Bruant bruant.d at
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
> <mailto:bruant.d at>> 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 <mailto:bruant.d at>> 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
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

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 '[]' 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

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
I realize that these (besides p.when and p.end) could just be replaced
by the Reflection API being adapted to work with promises.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list