Converting an existing object to a proxy

Mark S. Miller erights at
Thu May 26 19:13:13 PDT 2011

On Thu, May 26, 2011 at 5:04 PM, Cormac Flanagan <cormac at> wrote:

> [documenting/expanding some ideas briefly discussed at today's meeting]
> The current proxy proposal has a method to create a new proxy:
> var proxy = Proxy.create(handler, proto);
> We could extend this proposal to allow an existing object to be
> converted to a proxy, via:
> var proxy = Proxy.createFrom(object, handler, proto);
> Here, the return value 'proxy' is the same address as the argument
> 'object'.
> The original object thus becomes a proxy. Any state of the original object
> is discarded.
> This extension appears to support additional applications, such as
> registering an observer on an existing object. The target object would
> first be cloned, then the target object would be converted into a proxy
> that
> dispatches to the cloned object, but which also notifies observers about
> accesses/updates to the (now proxified) object.
> There are a number of open issues relating to security etc:
> In particular, what objects can be proxified in this way - perhaps not
> frozen object,
> or objects with non-configurable properties or with unique names.

In today's meeting, I made two suggestions along these lines:

* Given the current proxy semantics, we should allow this only if the
object-to-be-proxified is extensible and has no non-configurable own
* We have on occasion discussed modifying the proxy proposal so that
individual properties could be fixed rather than just the proxy as a whole.
(Note: I am not in favor of such a change, but it could be done soundly.)
Given that this change to proxies were done, then we should allow
proxification only if the object-to-be-proxified is extensible, period.

In both cases, as you state, one effect of the operation is to remove all
configurable own properties from the object. In both cases, we can adopt the
rationale that the object-to-be-proxified could not have taken any action
inconsistent with it always having been a proxy.

In both cases, we need the further restriction that it is a kind of object
that can be emulated by a proxy. Today, this is technically only objects of
[[Class]] "Object" or "Function", but we're talking about relaxing that in
any case.

> A design goal is that for any object that could be proxified,
> we can replace it with a proxy in a way that is semantically transparent.
>       - Cormac

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

More information about the es-discuss mailing list