15

I read somewhere that using prototype to extend native objects (String, Number, Array, etc.) was a bad idea. Is this true? Why or why not?

josh3736
  • 139,160
  • 33
  • 216
  • 263
Elliot Bonneville
  • 51,872
  • 23
  • 96
  • 123
  • 9
    This is a perfectly valid question of some worth, imo. It shouldn't be closed. – Elliot Bonneville Apr 17 '12 at 18:50
  • http://stackoverflow.com/faq#dontask says it isn't. – vascowhite Apr 17 '12 at 19:33
  • Basically a dup http://stackoverflow.com/questions/8859828/javascript-what-dangers-are-in-extending-array-prototype/8859941#8859941 – Jamund Ferguson Apr 17 '12 at 19:54
  • See also: [Why is extending native objects a bad practice?](http://stackoverflow.com/questions/14034180/why-is-extending-native-objects-a-bad-practice) – Bergi May 14 '14 at 15:00
  • Who closed this question? GTFO! This is completely valid and should be reopened. This is a HUGE issue in code quality. @vascowhite what guideline in there says this shouldn't be a question? – B T Apr 22 '15 at 03:30
  • See also: [Revisiting extending native prototypes after ECMAScript 5](http://stackoverflow.com/q/11781878/1048572) and [Modifying built-in prototypes in ES6](http://stackoverflow.com/q/36746555/1048572) – Bergi Jun 04 '16 at 16:40

3 Answers3

5

I don't think it's bad. If you have a look at Ruby on Rails, very many native objects are extended with custom functionality and it's a very good framework.

What would be bad is if you change existing methods on native objects. this could cause unforseen consequences.

Andreas Linden
  • 12,489
  • 7
  • 51
  • 67
  • Ah, okay. Yeah, that would make sense. – Elliot Bonneville Apr 17 '12 at 18:51
  • The real problem though is that you don't know what methods will exist in the future (e.g. if they are added to the standard). You can keep overwriting them and your own code will continue to work, but you won't be able to upgrade libraries that will try to use the new native methods in the future. – Bergi Sep 03 '21 at 23:36
5

There's a great discussion about this in this video from JSConf 2011 by Andrew Dupont. http://blip.tv/jsconf/jsconf2011-andrew-dupont-everything-is-permitted-extending-built-ins-5211542

Basically the points are:

  • Don't extend Object.prototype
  • Some people might like to extend things, some people don't
  • You need to know what you're doing
  • Don't use two libraries that extend things, because it can be bad
  • Extending prototypes to add standard functionality is almost always ok.
Jamund Ferguson
  • 16,721
  • 3
  • 42
  • 50
1

I would stay clear of extending/modifying behavior of native objects.

It at least makes sense when developing in a team environment.

Simply because, months later, another developer writing another independent piece of code isn't immediately going to recognize the changed behavior unless documented somewhere and made aware of it prior to starting his task.

Instead, I suggest encapsulating/"namespace"-ing all such functionality such that somebody may chose to or not to use the modified functions.

Also, native objects and their methods are thoroughly tested for wide-ranging cases. So you you'd have to be completely sure of what you're doing before modifying native functionality.

Robin Maben
  • 22,194
  • 16
  • 64
  • 99