On __proto__ as a magical data property

Geoffrey Sneddon gsneddon at opera.com
Thu Jul 19 12:46:12 PDT 2012

On 18/07/12 21:28, Brendan Eich wrote:
> Ollie: IIRC, JSC used to do what Rhino still does (last I looked):
> specialize __proto__ in the compiler or runtime (but either way, ahead
> of property lookup). True?
> That's definitely not on the table. Accessor vs. magic data property is
> the high-order choice, which at the May TC39 meeting we made in favor of
> magic data property.

This is the same as what Carakan had until recently (it was 
special-cased in both the compiler and property lookup, the latter 
needed to handle cases where it wasn't statically determinable).

 From my point of view, what we have now is entirely less powerful than 
what we had previously, having an accessor property that can be deleted 
and having a setter that cannot be accessed ("set" on the property 
descriptor is poisoned). The latter is mainly done for the sake of not 
having a context check in [[ProtoSetter]], as the strawman:__proto__ 
accessor alternative had — we simply don't have the context for most 
objects, and I loath the add the overhead of it. Making the setter 
inaccessible resolves the SES concerns without adding further overhead 
(excluding the one extra branch in Object.getOwnPropertyDescriptor) in 
code that does that does not use __proto__.

One of the concerns raised before was mutating prototypes of host 
objects: this has always been possible in Carakan and hasn't caused any 
issues, so I don't see any reason to remove this capability. Given we've 
had issues before with the overridden [[Get]], [[Put]], etc. not 
special-casing everywhere correctly, I'd much rather minimize 
special-casing and use an accessor property.

Geoffrey Sneddon — Opera Software

More information about the es-discuss mailing list