[Harmony Proxies] Proposal: Property fixing

Mark S. Miller erights at google.com
Fri Jun 17 14:21:01 PDT 2011

On Fri, Jun 17, 2011 at 1:50 PM, David Bruant <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

> 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

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

More information about the es-discuss mailing list