On Sun, Jan 29, 2012 at 6:25 PM, Allen Wirfs-Brock <al...@wirfs-brock.com>wrote:
[...]
> I would specify it as a modification to the normal [[Get]] and [[Put]]
> behavior that special cases on the property key value "__proto__". That
> special case (of [[Put]]) would not call [[DefineOwnPropertry]]. It would
> include check the prototype chain but that is part of the proposed
> semantics.
>
Then how would you explain the absence of magic after
delete Object.prototype.__proto__;
Object.prototype.__proto__ = 8;
? After these two lines, it should be a normal data property with value 8.
If the original property is an accessor, then this falls out nicely -- the
magic is in the setter, which is dispensed with in the first line.
If we do make __proto__ appear to be a data property, I think the right way
to do it is to specify (and probably also to implement) it as an accessor,
but then to specify magical behavior for [[GetOwnProperty]] that lies --
reporting that it is a data property. However, starting from that
assumption, I become increasingly uncomfortable with other implications:
When should [[DefineOwnProperty]] maintain the illusion vs simply replace
it with the property described by the arguments to [[DefineOwnProperty]]?
Perhaps the least surprising would be that any call
to [[DefineOwnProperty]] replaces the magic with the property described.
But any answer to this question will be surprising in some circumstances.
> This seems like a perfectly reasonable way to specify this. As __proto__
> does indeed affect the property access semantics for every object. Of
> course, I'm only talking specification. How you accomplish it in your
> implementation is up to you.
>
> There are other, alternatives.
>
> If we were willing to only define obj.__proto__ and exclude
> obj["__proto__"] I could specify it in 11.2.1 as a special case semantics
> of dot property access notation and have to extend any of the internal
> methods.
Again, if you specify it this way, how would you cope with deletion
followed by addition?
>From this discussion, I'm leaning towards Gavin's position. The first
element of language design style perhaps should be "Omit Needless Magic".
Your five cases you enumerated are not needless. Aside from the toxic waste
of non-strict mode, we are left with only three cases, all of which have to
do with indexing into the array-like types Array and String. The trouble
caused by array length has been quite painful, even though it is
non-configurable. The problems I raise above happen when combining magic
with configurability, which doesn't have any precedent among strict native
objects.
The one argument I know for the magic, which initially convinced me, is the
tighter intra-frame restriction that results. But this extra tightness is
AFAICT not relevant to security, given that __proto__ is limited to its own
frame and can be deleted. Are there any other arguments in favor of magic
here?
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
