2011/11/29 Allen Wirfs-Brock <[email protected]> > The only issue that I know of relates to the fact that access to remote > objects state probably requires the use of async APIs and call backs while > all of the Mirror APIs I have ever seen are most naturally expressed in a > synchronous style. I'm not sure what the best resolution of that issue > will be. It certainly would be possible to make an async mirrors API that > also works with local objects. Anybody writing code that needed to work > with any kind of mirror would want to use that async API. However, that > would be awkward and expensive for cases where you know that synchronous > access is possible, such as probably most Proxy uses of reflection. Perhaps > for those cases a simpler synchronous mirrors API is needed. > Unfortunately, that would leave us with two variants of the mirrors API. >
I agree with your analysis. Having both sync and async variants of the mirrors API is unfortunate, but I think it's absolutely necessary if you want mirrors to work with remote objects. I think most on this list will agree that hiding asynchrony is to be avoided. But perhaps the sync and async mirror APIs could be developed such that there is a trivial (perhaps mechanical) conversion between both. (If we would have promises, the async API could be the sync API with some (return) types lifted from T to Promise<T>) My position at this time is that Mirrors are promising, but the details still need to be worked out (especially re. remote objects) and it's a pretty big design exercise. Therefore, this may be a task better left to userland libraries in the short term. > BTW, it occurs to me that there probably is a similar issue if anyone > tries to use Proxy to actually create a remote object access facade. > Proxy Handler calls are synchronous but what if a trap handler (say a get) > needs to make an async call to a to obtain the state needed to produce the > value returned by the trap... > Yes, two relevant points with respect to this: 1) Mark and I tried to express something like this: an "eventual" reference to a local object, enforcing asynchronous access to its target. The example is on the old harmony:proxies page: < http://wiki.ecmascript.org/doku.php?id=harmony:proxies#an_eventual_reference_proxy > This code depends on promises (the "get" trap returns a promise for the result) and basically enables only synchronous access to properties known to be non-configurable or non-writable. It's a good example of a piece of code that exploits the new ES5 "invariants" to be able to safely cache immutable properties. Promises are really the abstraction you want to bridge synchronous APIs with asynchronous operation. 2) When layering remote objects over a restful API, ideally you want obj[name] to perform an HTTP GET and obj.name(a,b,c) to perform an HTTP POST. Proxies cannot distinguish property access from method invocation (which is just get+apply), so they currently can't perform the above mapping. Cheers, Tom
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
