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.
> 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.
>
> 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?
>
I think the loophole idea suggests this as well.
>
> 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)
>
Oops. You're right, this is missing. It is a spec bug and needs to be added
to the errata.
> - 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.
> - etc.
>
> David
>
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
