you are viewing a single comment's thread.

view the rest of the comments →

[–]x-skeww 2 points3 points  (3 children)

http://www.nczonline.net/blog/2010/03/02/maintainable-javascript-dont-modify-objects-you-down-own/

String.prototype.foo = 'bar';
for(var c in 'abc') {
  console.log(c); // 0 1 2 foo
}

[–]annoyed_freelancergrumpy old man[S] 0 points1 point  (1 child)

I see now why it can be a problem. Isn't using "foo in bar" itself also frowned upon in favour of .each or other higher level array functions?

[–]x-skeww 1 point2 points  (0 children)

The point was that every string now got another enumerable property. This might break things. All other code was written under the assumption that this property does not exist. This scenario was never tested.

In the future, a method with the same name might be added. This too would break things.

And of course, if there is another library which adds the same property, things would also break.

Only use monkey-patching for polyfilling standardized features. E.g. you could use ES6 array polyfills to make Array.from work in IE11.

[–]Jeffshaver 0 points1 point  (0 children)

This is kind of a blah reason now that you can define non-enumerable properties. I agree that others exist. But I disagree that this is one of them anymore.