Readdition of __proto__

Andrea Giammarchi andrea.giammarchi at gmail.com
Mon Oct 14 13:15:38 PDT 2013


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 <
inglor at gmail.com> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131014/f9d2199f/attachment.html>


More information about the es-discuss mailing list