On __proto__ as a magical data property
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?
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.
> 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).
>> es-discuss mailing list
>> es-discuss at mozilla.org
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss