Fwd: Object.prototype.__proto__
It is my understanding of B.3.1 that Object.prototype.proto’s only use is as a flag to switch off proto for all objects (I’m assuming in settings similar to Caja). Wouldn’t it be better to introduce a real boolean flag, along with a unique name object?
No.
First, proto is what it is, a de-facto standard (albeit with non-configurability in some implementations, a bug to fix), and adding some new switch elsewhere won't change things. So what you propose is redundant (given configurability).
Second, what's wrong with |delete Object.prototype.proto| as the explicit, symbol-free (symbol = unique name) way of turning off proto for a given global object and object graph generated within that scope? It's simpler and more direct than setting some other property for a side-effect.
OK, so this way of switching proto off for all objects is already de-facto standard? Didn’t know, thought it was introduced with ES6. If so, then the de-facto standard obviously beats other ideas. If not then I don’t hate the delete, I just think that overloading proto to be an off-switch in a single object feels slightly wrong.
Is switching off proto always an all-or-nothing proposition? Or will it be possible to selectively switch it off (e.g. by creating an object whose [[Prototype]] is null)?
The only issue remaining with proto is whether it is a magic data property, or an accessor with poisoned get and set pills on reflection.
Ah, so the spec isn’t (possibly) yet final here(?) At the moment it’s a magic data property (spec-wise), right?
On Sep 28, 2012, at 8:00 AM, Axel Rauschmayer wrote:
It is my understanding of B.3.1 that Object.prototype.proto’s only use is as a flag to switch off proto for all objects (I’m assuming in settings similar to Caja). Wouldn’t it be better to introduce a real boolean flag, along with a unique name object?
No.
First, proto is what it is, a de-facto standard (albeit with non-configurability in some implementations, a bug to fix), and adding some new switch elsewhere won't change things. So what you propose is redundant (given configurability).
Second, what's wrong with |delete Object.prototype.proto| as the explicit, symbol-free (symbol = unique name) way of turning off proto for a given global object and object graph generated within that scope? It's simpler and more direct than setting some other property for a side-effect.
OK, so this way of switching proto off for all objects is already de-facto standard? Didn’t know, thought it was introduced with ES6. If so, then the de-facto standard obviously beats other ideas. If not then I don’t hate the delete, I just think that overloading proto to be an off-switch in a single object feels slightly wrong.
Is switching off proto always an all-or-nothing proposition? Or will it be possible to selectively switch it off (e.g. by creating an object whose [[Prototype]] is null)?
The only issue remaining with proto is whether it is a magic data property, or an accessor with poisoned get and set pills on reflection.
Ah, so the spec isn’t (possibly) yet final here(?) At the moment it’s a magic data property (spec-wise), right?
the current draft spec. for proto is at best tentative and will be changed. It has no significance other than signaling an intent to fully specify proto.
My bad, I sent the previous email to es-discuss-owner instead of to es-discuss. Forwarding Brendan’s answer to everyone.
Begin forwarded message: