Readdition of __proto__

Benjamin (Inglor) Gruenbaum inglor at
Mon Oct 14 13:33:32 PDT 2013

__Thanks__ ! This is really above and beyond what I could have asked for. I
really wish there was an easy way to search the list like tags. I've been
reading for a while but when I want to bring up, learn more about or
discuss things - not being able to search really sucks. It makes me want to
avoid things because I know how frustrating repetition can be.

My opinion is probably a bit radical (not sure how many people here agree
with it), feel free to skip it as it's probably more of a rant :P

No, honestly - don't read it. It's repeating things that have probably been
said here before but I couldn't find (well, other than Branden here ).

>  * it's widely available across all mobile and modern desktop browsers

So is `with` but that still doesn't work in strict mode. I don't see why
having a feature people agree is bad (at least in the way it's currently
used) makes adding it for a standard a good idea. You can standardize it
and still not require browsers to implement it. If you choose to implement
__proto__ then... .

> it's faster than ``

I __hope__ this is not really an argument people are considering for adding
__proto__ to the spec. An optimization for
`` can be done instead on
vendor level.

>  * some library early adopted `__proto__` and few others followed making
a _de facto used_ approach to easily hot/swap inehritance

This is the most problematic argument here in my opinion. We have this
beautiful prototypical inheritance system in JavaScript that lets us write
clean and expressive code by not pretending we have some half working type
system and instead embracing behavioral typing. It's really great and I
really like it.

This behavioral typing system entails that we act sensible about our types,
inheritance can really work nicely and if I keep to the LSP and other
common design principles I find that my code in JavaScript is a lot more
expressive than similar OOP code in structurally typed languages.

Being able to mutate __proto__ breaks this. It breaks it bad. Suddenly, my
`Dog` stops being an `Animal` or my `Car` stops being a `Vehicle`. This
makes no sense, why would we enable people to break behavioral typing like
this? This is just like the `delete` operator.

The object creation case and getPrototypeOf make a lot of sense but
mutating __proto__ _after_ an object has been created sounds like a
horrible broken approach that shoots behavioral typing in the foot.
Especially when I'm __removing__ stuff from the prototype of an object.

Sorry for the long rant if you've gotten this far.

On Mon, Oct 14, 2013 at 11:15 PM, Andrea Giammarchi <
andrea.giammarchi at> wrote:

> 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 `` 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](
>   * 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> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list