On Jul 18, 2012, at 1:28 PM, Brendan Eich <bren...@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.orendo...@gmail.com> >> wrote: >> >>> On Wed, Jul 18, 2012 at 4:35 AM, Andreas Rossberg<rossb...@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@mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
