Le 29/11/2011 21:24, Mark S. Miller a écrit : > On Tue, Nov 29, 2011 at 11:03 AM, David Bruant <[email protected] > <mailto:[email protected]>> wrote: > > Le 29/11/2011 19:05, Mark S. Miller a écrit : >> On Tue, Nov 29, 2011 at 10:01 AM, David Bruant >> <[email protected] <mailto:[email protected]>> 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
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
