Direct proxies update

Tom Van Cutsem at
Tue Nov 29 03:00:35 PST 2011

2011/11/29 Allen Wirfs-Brock <allen at>

> 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

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:

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,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

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

More information about the es-discuss mailing list