Le 17/06/2011 21:41, David Bruant a écrit : > > To summurize fixed propeties property-specific trap behaviors, one > could say that: > - defineProperty trap is called (and its return value is meaningful as > explained on the current strawman) > (if approved) - getOwnPropertyDescriptor trap is called (and its > return value is meaningful the same way) > - delete rejects ...wait a minute. There is no invariant imposing this. There is an invariant asking to a property that might /disappear/ to show "configurable:true" but it does not prevent from manually deleting a property with "configurable:false", does it? I agree that this is the expectation we have from a native object, but I am not sure this is enforced by the spec on abnormal native or non-native (host) objects.
Regardless of the very delete trap issue, the more I think about it, the more I realize that we're slightly moving to a position where we put invariant enforcement code: the getOwnPropertyDescriptor trap imposes "configurable:true", unless it has been noticed that this very property has been noticed (or set) with "configurable:false" before, in which case, check against previously returned/set descriptor, etc. Would it cost that much more to just call traps and put the invariant enforcement code at the relevant places instead of the bicephal property fixing proposal? Also, I think that there might be missing invariants like: - if for a property, [[Configurable]] has been set to false or observed as false, it must stay like so (otherwise, all other invariants relying on "configurable:false" are just pointless) - The first observed value of [[Prototype]] of an object must remain throughout the program lifetime - etc. David
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
