On 18/07/12 21:28, Brendan Eich 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.
This is the same as what Carakan had until recently (it was
special-cased in both the compiler and property lookup, the latter
needed to handle cases where it wasn't statically determinable).
From my point of view, what we have now is entirely less powerful than
what we had previously, having an accessor property that can be deleted
and having a setter that cannot be accessed ("set" on the property
descriptor is poisoned). The latter is mainly done for the sake of not
having a context check in [[ProtoSetter]], as the strawman:__proto__
accessor alternative had — we simply don't have the context for most
objects, and I loath the add the overhead of it. Making the setter
inaccessible resolves the SES concerns without adding further overhead
(excluding the one extra branch in Object.getOwnPropertyDescriptor) in
code that does that does not use __proto__.
One of the concerns raised before was mutating prototypes of host
objects: this has always been possible in Carakan and hasn't caused any
issues, so I don't see any reason to remove this capability. Given we've
had issues before with the overridden [[Get]], [[Put]], etc. not
special-casing everywhere correctly, I'd much rather minimize
special-casing and use an accessor property.
--
Geoffrey Sneddon — Opera Software
<http://gsnedders.com>
<http://opera.com>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
