On Tue, Nov 29, 2011 at 11:03 AM, David Bruant <bruan...@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 <bruan...@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.
>
> Promises and the unifying Q(a).when seems to be what save us from
> designing two APIs. Looking forward to seeing this in ECMAScript.
>
Me too! Except for the infix "!" sugar, all this can be accomplished today
by using a Q library, such as Kris Kowal's.
>
> 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?
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
