On __proto__ as a magical data property

Brendan Eich brendan at mozilla.org
Wed Jul 18 13:34:20 PDT 2012

Oliver Hunt wrote:
> On Jul 18, 2012, at 1:28 PM, Brendan Eich<brendan at mozilla.org>  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.
> Um.  That what i just said.

No, we aren't using the same exact meaning of "magic".

>    We used to have a magic property that could not be killed.  Now we have an accessor on the prototype.  That is: something less powerful that can be removed.

The "could not be killed" also was not the same between JSC and 

Previous-JSC: magic data property handled before any other id lookup 
logic (right? that's what I'm trying to pin down), not deletable.

SpiderMonkey: magic data property that's really a "native accessor", not 
reflected as such, and (this part is independent and a one-line change 
to fix today) not configurable.

These are two different approaches. Saying what JSC had was more 
powerful because you couldn't override or delete it is also a different 
meaning of "more powerful" from the one TC39 considered in May: exposing 
a setter that might leak unmonitored into malware.

So we really were saying three different things using more or less the 
same words :-P.


More information about the es-discuss mailing list