Le 15/07/2011 11:44, Tom Van Cutsem a écrit : > 2011/7/14 David Bruant <[email protected] > <mailto:[email protected]>> > > + 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 > though. > > > > I'll give a follow-up here when I'm done. > So, here it is: > > https://github.com/DavidBruant/HarmonyProxyLab/tree/master/NonExtensibleProxies > 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 > "already > 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 > whether > 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 + > getOwnPropertyDescriptor). 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 [1] ? > > > Also, none of the 3 invariants regarding [[Extensible]]=false are > about > property names enumeration. Is there just no invariant to hold on > enumeration? If there is none, well, no need to do O(n)-ish > enforcements! > No thought on this point? That's pretty critical in terms of performance and could by itself compromise the consideration of the invariant enforcement model. David [1] https://mail.mozilla.org/pipermail/es-discuss/2011-March/013366.html
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
