Hacker Newsnew | comments | show | ask | jobs | submit login

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() {}}...)

As 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....

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_operato...


Yeah, 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.


Applications are open for YC Winter 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact