Yes, it's hard to search in this mailing list but luckily not everyone in here will tell you not to be "that guy that clearly didn't read anything and is just annoying" ^_^
Since I've personally pushed to drop `__proto__` I might be the right person to give you pros and cons. Feel free to ask me more, if necessary (off-topic: the double underscore to talk about dunder proto is a hilarious must) __Pros__ * some library early adopted `__proto__` and few others followed making a _de facto used_ approach to easily hot/swap inehritance * it's widely available across all mobile and modern desktop browsers * it's faster than `Array.prototype.slice.call(genericCollection)` which is the unique place where Zepto library, probably the main reason dunder is still here, decided to swap `querySelectorAll` results ignoring incompatibility with IE Mobile at that time not so popular (then, one of the reason IE11 wanted to adopt it) __Cons__ * due lack of proper specs, every browser implemented such property in a slightly different way creating a [security and behavior mess across all browsers](https://gist.github.com/WebReflection/5370050) * due previous point, `Object.create(null)` may not be safe dictionaries since in some case adding a key `__proto__` will change the object inheritance instead of adding just the keyword proto * ES5 introduced `Object.getPrototypeOf` but not `Object.setPrototypeOf` which would ensure an explicit intent over the generic option instead of being a "bomb" keyword any object could potentially suffer for __Current Status__ Instead of formalizing its form, ES6 accepted `Object.setPrototypeOf` as described in specs and decided to silently move beside, but still have in specs, the dunder `__proto__` form, fixing at least a couple of related gotchas so that: * unless explicitly set as property, `__proto__` is a named property for every object that should not affect inheritance so that `obj["__proto__"]` or `obj[key]` where `key` is the string `"__proto__"` should not hot/swap the prototypal chain * `obj.__proto__` is still valid when explicit, it should fail with `Object.create(null)` object but it should be a quick shortcut to create inheritance too such `var obj = {__proto__: null}` keeping compatibility but avoiding troubles with `JSON` serialized objects where once again `{"__proto__":[]}` will behave as named property instead of prototype mutator. I hope these answers are OK and to all others, please correct me whenever you think whatever I've written is wrong. Best Regards, Andrea Giammarchi On Mon, Oct 14, 2013 at 12:51 PM, Benjamin (Inglor) Gruenbaum < [email protected]> wrote: > Let me start by apologizing for adding noise to the list. > > I looked for discussion of the standardization of __proto__ in the ES6 > spec and couldn't find any. This is probably my shortcoming but I didn't > know where to look or how to search the mailing list. > > I found a lot of threads discussing possible problems with > Object.create(null) and __proto__ but not the discussion and decision to > include it in the spec and to tell browser vendors to implement it. And > then Branden's "famous" reply where he says he thinks it's a horrible idea > :) > > Frankly, when I heard a while back it was introduced it surprised me (why > would objects suddenly change their prototype?) I'm really interested in > hearing the arguments and counter-arguments for/against it. > > Thanks again and sorry. > > Benjamin Gruenabum. > > > > _______________________________________________ > 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
