Direct proxies update

David Bruant bruant.d at
Tue Nov 29 11:03:35 PST 2011

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.

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){})').
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 and the unifying Q(a).when seems to be what save us from
designing two APIs. Looking forward to seeing this in ECMAScript.

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.

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

More information about the es-discuss mailing list