Andreas Rossberg wrote:
I have difficulties catching up with everything that has been said in
this thread, my apologies if I repeat parts of the discussion. Here is
what I thought we agreed upon earlier:
1. __proto__ is an accessor property on Object.prototype
2. reflecting it via Object.getOwnPropertyDescriptor gives you a poisoned setter
Not poisoned for all calls, though -- see the meeting notes from January:
https://mail.mozilla.org/pipermail/es-discuss/2013-February/028631.html
(find "__proto__" to search to start of the relevant notes).
3. __proto__ can be deleted from Object.prototype
4. __proto__ in object literals is a special piece of syntax
independent from (1)
Should (4) be independent from (3)? Ah, you get to this later.
I think this all makes sense, and we are working towards making V8
implement this. (3) implies that Object.prototype.__proto__ is
configurable, which should also imply that you can just remove the
setter, not the getter, which I believe addresses Alex' initial
request.
The main question I still had was what "poisoning" means. Currently,
V8 simply returns an always-throw function. Others (e.g. Brendan)
seemed to assume that we only poison sets for other realms.
That was discussed at the January meeting (I forget whether you were
there then). Look for ARV in the notes, at the end of the __proto__
discussion.
However, in that case, I actually think that there is no need to have
any special poisoning semantics when reflecting __proto__ -- mainly
because the cross-realm check is already necessary in the unreflected
case: you can construct an object o in realm A with an
Object.prototype from another realm B on its proto chain. If you
deleted __proto__ on realm's A Object.prototype, I don't think it
should still be possible to assign to o.__proto__, should it?
Why not, if in realm A we evaluate 'var o =
Object.create(B.Object.prototype)'? You specified 'delete
A.Object.prototype' happened, and A.Object.prototype is not on o's proto
chain.
If
that's so then there is absolutely nothing magic remaining about
__proto__ as a property.
Did you get something switched between A & B above? Either that, or I
still need coffee!
As for __proto__ in object literals, I definitely agree with Allen and
Mark that this should be special syntax, and not dependent on
Object.prototype.___proto__, for the reasons mentioned.
Ok, I can go along here. This is quite different from ES5 + de-facto
__proto__ as implemented by real engines, but without configurable
Object.prototype.__proto__ it has not thus far (AFAIK) been observable
-- so no compatibility break.
Whether a
difference should be made between quoted and unquoted I don't know, I
must have missed the rationale for such a move.
I think we're not going to induce vomiting by making a quoted vs.
unquoted distinction, in light of Mark's point about computed property
names.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
