Converting an existing object to a proxy

Sean Eagan seaneagan1 at
Fri May 27 08:10:24 PDT 2011

I think the separation between proxies and regular objects is too
much.  I would prefer to think of proxies as just a special kind of
object.  All objects could be thought of as having a handler (
[[Handler]] ), and "proxy objects" could be those objects whose
handler is an actual ES object as opposed to an abstract language
specification object.  This would be similar to the distinction
betweeen "data" and "accessor" properties, since you could think of a
default abstract [[Set]] and [[Get]] implementation for property
descriptors.  Then fixing a proxy object could just be thought of as
setting the object's [[Handler]] to an abstract specification handler,
and Proxy.createFrom can just be thought of as setting the object's
[[Handler]] to an actual ES object.  The abstract [[Handler]] could
either be implemented via pseudocode similar to the ES5 spec or by
actual ES code if a testable / executable object spec is desired.

I've been working on a concept called "object descriptors" which are
an object level equivalent of property descriptors.  One of the object
descriptor attributes I'm including is "handler".  Object descriptors
could also have a "configurable" attribute which could control whether
an object's "handler" (and other attributes) can be changed.

On Fri, May 27, 2011 at 9:21 AM, Brendan Eich <brendan at> wrote:
> On May 27, 2011, at 3:04 AM, David Bruant wrote:
> The idea of permitting this "becomes" operation only for extensible objects
> with configurable properties is crucial.
> Is it? The first time I heard about the "become" operation was in the
> context of the proxy fix trap. Second time was this message. It doesn't
> sounds crucial yet to me.
> The "crucial" applied to both "only for extensible objects with configurable
> properties" in that sentence. ;-)
> The issue as I understand it is not becomes per se (more below), rather that
> an extensible object with configurable (own) properties could have those
> properties wrapped by accessors to emulate some of the intercessive power of
> proxies. From the security point of view, you want frozen and sealed
> objects, at least, to be immune to proxification because they are immune to
> such property-by-property wrapping with accessors, today.
> See Mark's reply on the list dated 7:33pm yesterday.
> The motivation is to unify ideas in proxies (in Harmony) with those proposed
> in
> I hadn't read this proposal yet. Thanks.
> I think that this discussion raises the following question:
> Should all usages of the "become" operation be associated with proxies?
> We are not exposing becomes in the language -- certainly not for two
> arbitrary live objects.
> In both the proxy fix case, and in this Proxy.createFrom case, one of the
> two objects is a newborn, not yet accessible. We brain-transplant between
> the accessible and inaccessible, swapping the objects' data. The identity is
> preserved but the internal and own properties are exchanged.
> Questions about the proxify-existing-object case:
> 1. Won't the proxy want the original "brain", the one transplanted into a
> newborn proxy (now "become" the regular object)?
> 2. Will the costs here be acceptable compared to something unstratified
> requiring no extra object, a la strawman:observe?
> /be
> _______________________________________________
> es-discuss mailing list
> es-discuss at

Sean Eagan

More information about the es-discuss mailing list