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.
/Andreas On 27 May 2011 04:13, Mark S. Miller <[email protected]> wrote: > On Thu, May 26, 2011 at 5:04 PM, Cormac Flanagan <[email protected]> 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 > properties. > * 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 > > > > -- > Cheers, > --MarkM > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
