".. lot of debate about whether or not extending the Prototypes of a native type in JavaScript is a good idea or not". There is no debate - don't do this in production code. But, it has its place while learning the ropes.
If you MUST extend built-in types (see above) - prefix it with something. That may be your org name, initials or your favourite namespace name.
It is simply bad, because whenever we share the code, we never know which libary/module is changing prototype.
With static methods on class, or a static method implies that this is an extension and in module pattern, the location of module will show up where the extension logic extends. It is important to track dependencies.
A really big problem is tracking all that "cool stuff" in the code-base. A new-comer just seems confused about why a particular "feature" works in one place and not the other. And, you also run the risk of conflicting with a future update (small risk over the course of years, if not decades).
My comment seems snobbish on the second run - wasn't my intent though.
Thank you for the suggestion! That's actually helpful. And yes. I do agree. I think it's useful to know how to do it but I wouldn't recommend using it in production.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
".. lot of debate about whether or not extending the Prototypes of a native type in JavaScript is a good idea or not". There is no debate - don't do this in production code. But, it has its place while learning the ropes.
If you MUST extend built-in types (see above) - prefix it with something. That may be your org name, initials or your favourite namespace name.
It is simply bad, because whenever we share the code, we never know which libary/module is changing prototype.
With static methods on class, or a static method implies that this is an extension and in module pattern, the location of module will show up where the extension logic extends. It is important to track dependencies.
Well explained.
A really big problem is tracking all that "cool stuff" in the code-base. A new-comer just seems confused about why a particular "feature" works in one place and not the other. And, you also run the risk of conflicting with a future update (small risk over the course of years, if not decades).
My comment seems snobbish on the second run - wasn't my intent though.
Thank you for the suggestion! That's actually helpful. And yes. I do agree. I think it's useful to know how to do it but I wouldn't recommend using it in production.