On __proto__ as a magical data property
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