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__. Allen _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
