3 ms·
Here's the part I don't get: `Object.create`, as it's defined there, is a long-winded, roundabout way of saying {__proto__: o} People seem to think that t
by Cushman 15y ago
Here's the part I don't get: `Object.create`, as it's defined there, is a long-winded, roundabout way of saying
{__proto__: o}
People seem to think that this is functionality that was lacking from JavaScript; many of these same people have some inexplicable distaste for the (non-standard) `__proto__` property. What gives?
(Okay, technically it's {__proto__: o, constructor: function F() {}}...)
- alunny 15y agoAs I understand it, the main objection to `__proto__` is that it's writable, and thus not atomic with object creation. This creates a bunch of headaches for implementors for performance and security. More knowledgable people than myself discuss it on this es-discuss thread: http://www.mail-archive.com/es-discuss@mozilla.org/msg06142.html http://www.mail-archive.com/es-discuss@mozilla.org/msg06142.... There is a Harmony proposal for a "set prototype of operator" that would solve this problem; instead of writing: var newObj = {__proto__: OldObject, id: 5} You would write: var newObj = OldObject <| { id: 5 } Detailed here: http://wiki.ecmascript.org/doku.php?id=harmony:proto_operator http://wiki.ecmascript.org/doku.php?id=harmony:proto_operato...
- Cushman 15y agoYeah, I can understand how it makes implementors' lives easier... I just like it when they deal with annoying stuff so that I don't have to :) I know people don't use mutable __proto__ for anything useful, but it does enable some neat tricks. Personally I wish implementors would embrace it and optimize for it rather than trying to make it go away. As for the "prototype for" operator... that's disgusting.