3

Relating this thread : JavaScript better way to modify function prototype, I was wondering why mutating instances' __proto__ is a slow manipulation.

I know it is deprecated, I often read it on the web. But I have never found why. Why is it really deprecated, and why is it slow ?

Will setPrototypeOf() be a better solution, as for performance ?

Community
  • 1
  • 1
Tot
  • 873
  • 2
  • 13
  • 30
  • It's actually not deprecated anymore it has been re-introduced for compatibility reasons in ES6. It should _generally_ be avoided. Let's say you have an `Animal` and a `Dog` is an animal. What `__proto__` lets you do is to declare that "This dog is no longer an animal" which totally breaks object oriented design. It has some useful cases (like saying something is "No longer a NodeList, it is an Array like Zepto does) but those are rare and in my opinion generally not justified. – Benjamin Gruenbaum Feb 17 '14 at 22:57
  • Here is the [ES6 specification of `__proto__` by the way](https://people.mozilla.org/~jorendorff/es6-draft.html#sec-__proto___-property-names-in-object-initialisers) and here are arguments against it from language creator and Mozilla CTO Brendan Eich https://mail.mozilla.org/pipermail/es-discuss/2010-April/010917.html – Benjamin Gruenbaum Feb 17 '14 at 22:59
  • Alright, but I still wish to know why it is said as slow. ;) Though I quite understand it breaks OO design. However I have no other solution than setting `__proto__` if my "object" is a function (as described in the related thread) and if I don't want to modify `Function.prototype`. Thanks ! – Tot Feb 17 '14 at 23:08
  • can you make your "Classes" to work on a one-off, like this.bundle.name instead of this.name? that way, you can keep the bundle as a vanilla object and swap implementations at any time without killing runtime optimizations. as long as all the interchangeable methods know of and use ".bundle.", it's almost as handy as a aggregate type "hotswap", but without the cost. – dandavis Feb 17 '14 at 23:36

1 Answers1

2

I was wondering why mutating instances' proto is a slow manipulation.

The people who implemented the JavaScript language in your browser made a trade-off: They wanted to support this "esoteric" feature, but made the rest of the language faster by making this manipulation slower.

You should only worry about the speed of __proto__ after you write your program. For many use cases, the extra "slowness" will only result in a few miliseconds difference in the overall program, and nobody will care.

BraveNewCurrency
  • 12,654
  • 2
  • 42
  • 50
  • 1
    `[...] but made the rest of the language faster by making this manipulation slower.` : What do you mean exactly ? :o And alright, but I still wonder "why/how" algorithmically it is slow. Thanks for your answer. – Tot Feb 18 '14 at 22:55
  • I don't know the specifics. Imagine if the language copies `__proto__` to every object so that it will be super-fast to access. If you change `__proto__`, that will be slow because it needs to update every object. (I don't think that's what they do, but that's the kinds of trade-offs languages make.) – BraveNewCurrency Feb 22 '14 at 01:42
  • I see. In fact they try to prevent setting manually the `__proto__` because people could set anything to it and break the whole prototype philosophy. Alright, thank you for your help. :) So we may modify it only if we have absolutely no other choices. – Tot Feb 23 '14 at 22:19