+1 to everything, but I would drop the literal too instead of promoting two ways to do things.
off topic: I also hope __proto__ will be spec'd with a descriptor that exposes the setter as it is now in Firefox, and not only the getter, as conceptual language nonsense/restriction. On Sat, Apr 20, 2013 at 4:37 PM, Axel Rauschmayer <[email protected]> wrote: > __proto__ can be globally switched off by deleting > Object.prototype.__proto__. I’m assuming that that is useful for > security-related applications (Caja et al.). But I’m wondering: doesn’t > that go too far? I’m seeing three ways of using __proto__: > > 1. Read the [[Prototype]] of an object. Already possible via > Object.getPrototypeOf(). > 2. Set the [[Prototype]] of a fresh object created via an object literal > (i.e., an alternative to the rejected <| operator). Already (kind of) > possible via Object.create(). > 3. Mutate the [[Prototype]] of an existing object. > > Globally, I would only want to switch off #3. > Rationale: the only security-critical operation of the three(?) The use > case for performing this operation goes mostly away by ES6 allowing us to > subtype built-ins. Could #3 be forbidden in strict mode? > > #1 and #2 should not be possible if an object does not have > Object.prototype in its prototype chain. > Rationale: objects as dictionaries via Object.create(null) or { __proto__: > null } > > -- > Dr. Axel Rauschmayer > [email protected] > > home: rauschma.de > twitter: twitter.com/rauschma > blog: 2ality.com > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
