[Harmony Proxies] Proposal: Property fixing

David Bruant david.bruant at labri.fr
Sun Jun 19 04:36:42 PDT 2011

Le 17/06/2011 23:21, Mark S. Miller a écrit :
> On Fri, Jun 17, 2011 at 1:50 PM, David Bruant <david.bruant at labri.fr
> <mailto:david.bruant at labri.fr>> wrote:
>     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?
> If the delete succeeds, then the property disappears, so yes, this
> would be prohibited.
Ok. "Disappear" seemed to imply "not manually" to me, but I'm not a
native English speaker.
>     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.
> I'm not sure that the delete operation must throw, though I hope it
> must. But it cannot result in a non-configurable property disappearing.
Actually, the spec is not very precise on this point.
ES5.1 11.4.1 the delete operator "In addition, if a delete operator
occurs within strict mode code and the property to be deleted has the
attribute { [[Configurable]]: false }, a TypeError exception is thrown."
An exception is thrown, however, nothing is said on the destiny of the
property. Has it been deleted anyways? One can assume not, but the spec
leaves it implicit.

>     - The first observed value of [[Prototype]] of an object must
>     remain throughout the program lifetime
> For ES5.1, we explicitly do not prohibit changes to the [[Prototype]]
> on extensible objects. Neither do we provide any way to change it, but
> implementations that allow such changes do not thereby violate ES5.1.
> I believe we should prohibit this in ES-next, but I cannot say we yet
> have consensus on that.
> We do prohibit changes to [[Prototype]] on frozen objects. I think we
> prohibit such changes on all non-extensible objects, but no longer
> remember for sure.
The spec words are "if [[Extensible]] is false the value of the
[[Class]] and [[Prototype]] internal properties of the object may not be
modified."..."Implementation specific extensions that modify [[Class]],
[[Prototype]] or [[Extensible]] must not violate the invariants defined
in the preceding paragraph."
Based on that a decision has to be made between:
- changes to [[Prototype]] even on extensible objects should be prohibited
- getPrototypeOf should be a proxy trap.

And I am also going to ask the same question as usual: is this invariant
on extensible objects and prototype actually used (in SES for instance)?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110619/cfdf1c85/attachment-0001.html>

More information about the es-discuss mailing list