[Harmony Proxies] Proposal: Property fixing

Mark S. Miller erights at google.com
Sun Jun 19 10:00:59 PDT 2011


On Sun, Jun 19, 2011 at 4:36 AM, David Bruant <david.bruant at labri.fr> wrote:

> **
> 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>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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110619/e7e8765e/attachment-0001.html>


More information about the es-discuss mailing list