Readdition of __proto__

Andrea Giammarchi andrea.giammarchi at gmail.com
Mon Oct 14 13:49:08 PDT 2013


You are breaking an opened door with me and I've indeed pushed to **not**
have `__dunder__` specd but, for how much remote anger I still have against
some decision some famous library and its main author made few months ago
...

  * web developers and specially library authors are usually more pragmatic
than rational ... they solve problems. If something is widely adopted and
"works" they won't bother much with philosophy, I am sure you know what I
mean
  * performance is always a good argument. I agree that if everything is
screwed and slow, using `__proto__` instead of `slice` or `push` over a new
instance won't give you much (the whole story in Zepto is that the
collection has Zepto methods inherited so is not just slice but yeah, it
could have been done differently for sure)
  * JavaScript is better than just OOP, it uses prototype but also it's
able to borrow methods from everything and everywhere (mixin). Hot swapping
the proto might be an easy, simple, fast, shortcut to promote, downgrade,
or change state in a state-machine system with a single operation. In JS
you can composite deleting and adding new "methods" (aka: invokable
properties) so if you ave a similar approach you might want to opt for
`__dunder__`


Once again, I've been fighting to not have it in for some similar reason
and other security concerns plus it has been discussed infinite times and I
believe everyone participated.

The current status is the best option for everyone hoping whatever library
decides to hot/swap inheritance will do it with its own known
objects/instances instead of anything that goes through that library.

In such/latter case, I would simply ignore that library as too greedy.

Right now:
  * zepto and others will keep using `__proto__` going dirty
  * you can avoid all of this without problems
  * others will forget about this with new ES6 Class syntax

Annex B is also an indicator that such feature is secondary so it's not
something JS engines should absolutely have (these will in any case)

Best Regards



On Mon, Oct 14, 2013 at 1:33 PM, Benjamin (Inglor) Gruenbaum <
inglor at gmail.com> wrote:

> __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
> https://mail.mozilla.org/pipermail/es-discuss/2010-April/010917.html ).
>
> >  * 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 `Array.prototype.slice.call(genericCollection)`
>
> I __hope__ this is not really an argument people are considering for
> adding __proto__ to the spec. An optimization for
> `Array.prototype.slice.call(genericCollection)` 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 gmail.com> 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 `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/8f7d02bb/attachment.html>


More information about the es-discuss mailing list