Re: Interaction of named properties and own properties in the [OverrideBuiltins] case seems weird

On 2/26/15 9:24 AM, Boris Zbarsky wrote:
> I would like to propose changing this behavior.  Specifically, I would
> like to propose that whether an interface is [OverrideBuiltins] or not
> should not affect the interaction of named properties and own properties
> on [[Get]].

Oh, I forgot the key part.  With that change, the named property 
visibility algorithm would look like this (ignoring for the moment the 
problems with the proto walk):

1.  If O has an own property named P, then return false.
2.  If P is not a supported property name of O, then return false.
3.  If O implements an interface that has the [OverrideBuiltins]
     extended attribute, then return true.
4.  While prototype is not null:
     1.  If prototype is not a named properties object, and prototype
         has an own property named P, then return false.
     2.  Set prototype to be the value of the internal [[Prototype]]
         property of prototype.
5.  Return true.

In particular, all the complexity around unforgeable stuff goes away, 
since unforgeable things just create own properties.

-Boris

Received on Thursday, 26 February 2015 16:09:23 UTC