[Harmony Proxies] Proposal: Property fixing

David Bruant david.bruant at labri.fr
Fri Jun 17 13:50:53 PDT 2011

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110617/268ab16b/attachment.html>

More information about the es-discuss mailing list