1

I have seen some people regard extending the natives prototypes in Javascript with disdain. I was thinking about doing it, because of syntactic convenience. I.e.

function(array, element)

can be more cumbersome to write and less readable than

array.function(element)

But the second can only be acheived (AFAIK) by extending the Array prototype. Is there something wrong with extending native prototypes, and will doing this somehow haunt be me later?

Peter Olson
  • 139,199
  • 49
  • 202
  • 242
  • What makes this question any different from http://stackoverflow.com/questions/3795422 http://stackoverflow.com/questions/3577571 http://stackoverflow.com/questions/5575478 ? – Matt Ball Aug 11 '11 at 04:28
  • It's covered fairly well here: http://stackoverflow.com/questions/6585478/what-are-the-disadvantages-of-javascript-prototype-inheritance too – Joe Aug 11 '11 at 04:28
  • 2
    Here's another good article on this: http://perfectionkills.com/extending-built-in-native-objects-evil-or-not/ – OverZealous Aug 11 '11 at 04:30

1 Answers1

1

It can conflict with other libraries trying to do the same.

It can conflict with future methods added to native objects.

If anyone is using for (var i in array) without proper hasOwnProperty() checks, their code may/probably will break because the new method may show up in the iteration in older browsers.

jfriend00
  • 683,504
  • 96
  • 985
  • 979
  • 1
    You mean *without* proper `hasOwnProperty` checks? – icktoofay Aug 11 '11 at 04:31
  • But you can always check to see if it already exists to prevent clashes and make it future-proof. E.g. if I wanted to add `foo` to the Array prototype, I would first check `if(Array.foo)`. – Peter Olson Aug 11 '11 at 04:33
  • @Peter Of The Corn - you can only check if it already exists and defer to a built-in method if you KNOW that your method has the EXACT same implementation as the new built-in one. That can be safe for methods that are already introduced in newer browsers, but isn't feasible for ones that don't exist yet because you may be deferring to a built-in method that works differently than what you coded and tested your app with. – jfriend00 Aug 11 '11 at 04:37
  • The problem of overwriting methods is somewhat alleviated with the latest ECMA spec. So library assigns `Array.foo` and when done correctly `for(var i in Array)` will not show the property `foo` and `Array.foo=bar` produces an error. I know that not all browsers support this now, but given some time this particular argument may carry less weight. – qw3n Aug 11 '11 at 05:02
  • @qw3n - It will be a very long time before all browsers you might want to support have that ECMA feature. Because of that, you'd have to make sure nobody was unsafely iterating over an array. We're talking about the risks here. I'm not saying you can't do it, just discussing what the risks are. – jfriend00 Aug 11 '11 at 05:10
  • @jfriend00 check out this compatibility table http://kangax.github.com/es5-compat-table/ while it does not check for exact adherence to the spec it does mean that except for opera every major browser seems to be supporting ECMA script 5 – qw3n Aug 11 '11 at 13:18
  • @qw3n - please describe how that chart affects my answer or this question. – jfriend00 Aug 11 '11 at 14:43
  • @jfriend00 ECMA Script 5 has tried to solve some of the dangers of modifying native object prototypes. You mentioned that it would be a long time before that would happen. From the chart I'm saying that it looks like basic support is already available in all but one of the top 5 browsers. I'm not saying your answer is wrong I was just noting that with ES5 some of the issues are no longer a problem. And optimistically speaking it might not be so long in the future before ES5 is here. – qw3n Aug 11 '11 at 16:52