[Harmony Proxies] LazyReadCopy experiment and invariant checking for [[Extensible]]=false
david.bruant at labri.fr
Sat Jul 16 05:08:25 PDT 2011
Le 15/07/2011 11:44, Tom Van Cutsem a écrit :
> 2011/7/14 David Bruant <david.bruant at labri.fr
> <mailto:david.bruant at labri.fr>>
> + Mark to discuss ES5.1 invariants.
> > I'm working on an implementation. It will be independent from the
> > FixedHandler one. It should be possible to combine both easily
> > I'll give a follow-up here when I'm done.
> So, here it is:
> I have just commited but not tested. The reason is that I wondered if
> all this effort was worth.
> I've re-read the invariants in ES5 (last one on extensible not allowed
> to go from false to true omitted):
> * If the value of the host object’s [[Extensible]] internal
> property is
> has been observed by ECMAScript code to be false, then if a call to
> [[GetOwnProperty]] describes a property as non-existent all subsequent
> calls must also describe that property as non-existent.
> => To implement this, the handler just has to keep a record of
> observed as non-existent properties" and make sure [[GetOwnProperty]]
> respects the invariant by a lookup in this record.
> Which is bad since the set of "already observed as non-existent
> properties" is a potentially unbounded set determined by clients. We
> wouldn't want a proxy to have to remember all property names for which
> it ever replied "undefined".
True, I didn't think of that.
> * The [[DefineOwnProperty]] internal method of a host object must not
> permit the addition of a new property to a host object if the
> [[Extensible]] internal property of that host object has been observed
> by ECMAScript code to be false.
> => This one is a bit more tricky. "must not permit the addition of
> a new
> property" seems to assume that an object has a set of properties. But
> that's not really true for proxies. The engine has no way to say
> a property is defined in a proxy or not. Consequently, it cannot
> tell if
> [[DefineOwnProperty]] is called on a "new" or "old" property.
> This could be compensated by explicitely returning a list of property
> names in the fix/preventExtension trap.
> Indeed. I think it's still necessary that upon fixing a proxy, the
> proxy asks the handler for all of its own properties (either via the
> return value of fix() or by calling getOwnPropertyNames +
The return value of fix() sounds closer to the previous design.
Moreover, there is no need to get the property descriptor.
Non-extensible objects invariants are just about the properties
regardless of their property descriptor.
Also, in order to keep respecting non-configurable properties
invariants, it should be said that non-configurable property names are
appended to the return value of the fix trap.
> That gives it a fixed set of properties, making it at least easy to
> check the previous invariant without requiring unbounded storage
> (which also seems to be the way you have implemented it in your
> prototype, I noticed).
> Not sure how to deal with inherited properties, though.
Does it need to be addressed? Are there invariants requiring to enforce
something on how to handle inheritance?
> A fixed proxy may still have a non-fixed [[Prototype]], so its
> [[GetProperty]] and [[Get]] traps may still report new properties.
> OTOH, if the proxy's entire [[Prototype]] chain is also fixed, the
> constraints become more tight. A compromise could be that a
> non-extensible proxy can no longer virtualize inherited properties,
> only own properties.
Something like the inheritance-safe proxy idea  ?
> Also, none of the 3 invariants regarding [[Extensible]]=false are
> property names enumeration. Is there just no invariant to hold on
> enumeration? If there is none, well, no need to do O(n)-ish
No thought on this point? That's pretty critical in terms of performance
and could by itself compromise the consideration of the invariant
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss