On Sun, Jun 19, 2011 at 4:36 AM, David Bruant <[email protected]> wrote:
> ** > Le 17/06/2011 23:21, Mark S. Miller a écrit : > > On Fri, Jun 17, 2011 at 1:50 PM, David Bruant <[email protected]>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. > If the spec nowhere states this explicitly, I would consider it a spec bug to be added to the errata. The intent is clearly that the property not disappear in this circumstance. > > - 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: > a) changes to [[Prototype]] even on extensible objects should be prohibited > b) getPrototypeOf should be a proxy trap. > [labeled your bullets above so we can refer back to them] While I do not agree with "has to be made", I do agree with "should be made". Without changing either, the spec makes a consistent even if somewhat silly stance: x) It nowhere provides any means for modifying a [[Prototype]], so implementations in which [[Prototype]] cannot be modified are conforming. y) It prohibits changes to [[Prototype]] only on non-extensible objects, so implementations which allow such changes to extensible objects by unspecified means are conforming. Choosing #a implies loss of #y. Choosing #b implies loss of #x. I think we should chose #a and lose #y. If we can't agree on that, I think I prefer the status quo to choosing #b and losing #x, as it still leaves open the possibility that we could choose #a in the future. > > 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)? > In answering this question, I think we may have a bug. I think I may be counting on [[Prototype]] not changing in general, rather than only on non-extensible objects. I need to get back to you on that. Thanks for raising it! -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
