On __proto__ as a magical data property

Brendan Eich brendan at mozilla.org
Wed Jul 18 13:28:23 PDT 2012


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.

Jason: __proto__ as an accessor doesn't just "almost make sense", it 
actually does fit in the language, cycle checking and all. That is, you 
could self-host it in ES5 if you self-hosted prototype chains too.

Your suggestion of the setter checking that the receiving object inherit 
the built-in __proto__ before actually doing the "set" is interesting, 
but it seems to me that it means every set does a proxy-observable "has" 
operation. That's not something we do today -- maybe it's ok to add it 
-- but it is also overhead and opportunity for mischief. Or did you have 
a thought on how to silently probe for the property descriptor?

/be

Oliver Hunt wrote:
> JSC migrating __proto__ to accessors did not add any power, if anything it removed/reduced power.  The old __proto__ was an extraordinarily magical property that existed on every object.  It was not possible to remove/block it at all.  So anyone could make an accessor or function or implicit conversion that could arbitrarily change the prototype of an object.
>
> --Oliver
>
> On Jul 18, 2012, at 1:11 PM, Jason Orendorff<jason.orendorff at gmail.com>  wrote:
>
>> On Wed, Jul 18, 2012 at 4:35 AM, Andreas Rossberg<rossberg at google.com>  wrote:
>>> I agree with that. I'm not quite convinced that there are relevant security
>>> implication with an accessor semantics either.
>> If we want to be sure we're not adding any power here, the __proto__
>> setter should simply check that the receiver actually has the original
>> __proto__ property; if not, it should throw.
>>
>> That would be weird, but safe, and the weirdness would be isolated in
>> a section of the specification under the heading "__proto__ setter" in
>> an annex.  Containment!
>>
>>> I also don't think that array length counts as proper precedence.
>> Speaking as an implementor, I see array length as a precedent to be
>> avoided.  SpiderMonkey still doesn't implement all its quirks.
>>
>> I'm not surprised Waldo's experiment with accessor __proto__ went
>> smoothly.  That's because __proto__ as an accessor property almost
>> makes sense.
>>
>> Specifying an accessor property--plus a single special case for
>> ObjectLiterals, which we can handle in the front end--will make less
>> work and a nicer spec (that is, looser coupling, better isolation of
>> special cases).
>>
>> -j
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>


More information about the es-discuss mailing list