On __proto__ as a magical data property

Oliver Hunt oliver at apple.com
Wed Jul 18 13:30:47 PDT 2012


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.  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.

> 
> 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