Converting an existing object to a proxy
rossberg at google.com
Fri May 27 10:44:43 PDT 2011
I'm puzzled about this idea. I thought that one of the main design
goals of proxies was that they are transparent, i.e. you cannot tell a
proxy apart from a proper object. How can this be maintained for
Proxy.createFrom? AFAICS, there is no way you can perform this
operation on an object that already is a proxy.
On 27 May 2011 04:13, Mark S. Miller <erights at google.com> wrote:
> On Thu, May 26, 2011 at 5:04 PM, Cormac Flanagan <cormac at cs.ucsc.edu> 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
>> 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
>> 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
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss