CUTCODEDOWN
Minimalist Semantic Markup

Welcome Guest
Please Login or Register

If you have registered but not recieved your activation e-mail in a reasonable amount of time, please use our Contact Form for assistance. Include both your username and the e-mail you tried to register with.

Author Topic: To extend system objects or not?  (Read 265 times)

Jason Knight

  • Administrator
  • Sr. Member
  • *****
  • Posts: 378
  • Karma: +49/-1
    • CutCodeDown -- Minimalist Semantic Markup
To extend system objects or not?
« on: 2 Feb 2020, 10:29:17 am »
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.
Sorrow hides well in your shell. A fellow man with hurt to spare.
Dear one, here I am to share the fear. An act of kindness, without an amen.
Come in, the fire's warm. Burn the rope and dance some more.

Goos

  • Greenhorn
  • *
  • Posts: 2
  • Karma: +0/-0
Re: To extend system objects or not?
« Reply #1 on: 13 Feb 2020, 04:58:08 am »
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

  • Administrator
  • Sr. Member
  • *****
  • Posts: 378
  • Karma: +49/-1
    • CutCodeDown -- Minimalist Semantic Markup
Re: To extend system objects or not?
« Reply #2 on: 13 Feb 2020, 11:50:59 am »
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.
Sorrow hides well in your shell. A fellow man with hurt to spare.
Dear one, here I am to share the fear. An act of kindness, without an amen.
Come in, the fire's warm. Burn the rope and dance some more.

Goos

  • Greenhorn
  • *
  • Posts: 2
  • Karma: +0/-0
Re: To extend system objects or not?
« Reply #3 on: 13 Feb 2020, 01:37:37 pm »
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

  • Administrator
  • Sr. Member
  • *****
  • Posts: 378
  • Karma: +49/-1
    • CutCodeDown -- Minimalist Semantic Markup
Re: To extend system objects or not?
« Reply #4 on: 13 Feb 2020, 10:19:22 pm »
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.
« Last Edit: 13 Feb 2020, 10:22:22 pm by Jason Knight »
Sorrow hides well in your shell. A fellow man with hurt to spare.
Dear one, here I am to share the fear. An act of kindness, without an amen.
Come in, the fire's warm. Burn the rope and dance some more.

 

Advertisement