> Le 28/01/2012 18:16, Brendan Eich a écrit :
>> I don't think we should change __proto__ unnecessarily from current
>> implementations, including making it an accessor. Neither JSC nor
>> SpiderMonkey does that.
If the spec includes an optional normative definition of __proto__ that
requires it to be a configurable property of Object.prototype then a
significant rewrite of JSC's __proto__ implementation will be necessary.
That's okay – it seems worthwhile doing so to make it possible to delete the
__proto__ property. The logical way to implement this in JSC is likely as an
accessor property.
So the question for us is not whether changing our implementation is necessary
(it is), but rather whether having cleaned this up, we will then need to add
back in new magic to make __proto__ masquerade as a data descriptor to match
SpiderMonkey. The less magical __proto__ is the better, so this seems
undesirable. Since the implementation in JSC will need to change anyway, we're
motivated to aim for the least magical behaviour, but for SpiderMonkey, which
already has a better implementation for __proto__, I can see why requiring a
change would be undesirable.
On Jan 28, 2012, at 10:20 AM, David Bruant wrote:
> Regarding the specification (as optional normative) of __proto__ as an
> data descriptor, either the spec can invoke some magic (which is what
> implementations already do from an ES5 point of view) or redefine
> Object.prototype as a proxy. The target of this proxy would be the
> standard Object.prototype and the handler would just define some trap
> behavior that deal with __proto__.
Given this is __proto__ we're talking about, maybe it just isn't worth being
overly specific here?
How about we just specify that:
* The only permissible way to modify an object's [[Prototype]] is
through __proto__.
* __proto__ must be a property of Object.prototype.
* __proto__ must be configurable.
This would mean that any conforming implementation would have a easy,
spec-defined way to remove __proto__, without burdening browsers who implement
this as a data descriptor to change their implementations to make it an
accessor descriptor, or burdening browsers who implement this as an accessor
descriptor to change their implementations to make it a data descriptor.
Are there a significant practical benefit of a more restrictive specification
that this fails to cover?
cheers,
G.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
