To extend system objects or not?

[Jason Knight]

Years ago I heard that extending system objects like "Element" or "Math" was "bad".  Whilst I knew that legacy IE (of which I'm out of ***'s to give, my ***'s have run all dry) didn't do proper inheritance to live DOM Elements, in modern browsers what reasons are there for extending Array, String, Element, Object, Node, etc, etc being a "bad thing" you "shouldn't do".

The only one I know of is namespace collisions, and even in that case you could simply use uniform prefixes -- like a double underscore -- to mark them as "proprietary".

For example, what's wrong with:

Code: [Select]

Node.prototype.__flush = function() {
while (this.firstChild) this.removeChild(this.firstChild);
};

That would make it a "forbidden" technique just because it is being applied to Node?

Or...

Code: [Select]

Object.defineProperty(
String.prototype,
'__htmlSpecialChars',
{
get : function() {
return this.replace(/[&<>"']/g, function(m) {
return '&#38;#38;#' + m.charCodeAt() + ';';
});
}
}
);
The reason I'm asking is my original version of elementals was going to work this way, and I'm thinking on dragging Elementals 4 back to this, since IMHO:

Code: [Select]

var myString = 'This is a <test>';
console.log(myString.__htmlSpecialChars);

Would be vastly superior to:

Code: [Select]

var myString = 'This is a <test>';
console.log(_.htmlSpecialChars(myString));
// where _ is my elementals core object

Probably faster executing too. I know I was told legitimate reasons not to use this approach a decade ago, but damned if I can remember what they were. Was it literally just "IE7/earlier can't do that" and that's it?!?

Trying to challenge my own assumptions here; assumptions that may have been based on misinformation, misunderstanding, or that flat out simply no longer apply years later.

[Goos]

One reason would be that if another library would also extend native objects but with a slightly different implementation, those libraries would break each other. Therefore it's good practice for each library to have it's own namespace.

[Jason Knight]

One reason would be that if another library would also extend native objects but with a slightly different implementation, those libraries would break each other. Therefore it's good practice for each library to have it's own namespace.

Aka namespace collision, one of the conditions I'm already aware of and mentioned in the initial post.

[Goos]

You're right, I missed that sentence. Another reason was for-in loops without hasOwnProperty enumerating over prototype properties. So you should definately use Object.defineProperty to make them non-enumerable.

[Jason Knight]

You're right, I missed that sentence. Another reason was for-in loops without hasOwnProperty enumerating over prototype properties. So you should definately use Object.defineProperty to make them non-enumerable.

Which is why defineProperty is exactly what I'd used if I target Object.

Though I'm not sure why someone would do a for-in loop on Element, String, or Math... though I say the same thing about having to check for null on a String object polyfill. I mean I get that call/apply can bomb, but that should be system level handled, not brute force coded.

Seriously, on things like String polyfills having to say "if ('null' == typeof this) Throw new Error(" is pure derp. How the blazes does an object method run if "this" is null? By the user forcing null with "call", in which case that should be the user's fault and we shouldn't have to bend over backwards for their stupidity.