Web Analytics Made Easy -
StatCounter Is extending system objects/prototypes bad? - CodingForum

Announcement

Collapse
No announcement yet.

Is extending system objects/prototypes bad?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Is extending system objects/prototypes bad?

    I'm asking this across several forums as I'm looking for as many eyeballs on target with this.

    I remember about a decade ago people telling me that doing something like:

    Code:
    String.prototype.__condense = function() {
    or

    Code:
    Object.addProperty(String.prototype, '__htmlSpecialChars', {
    Was bad. I can only remember two of the reasons:

    1) Possibility of namespace collision with future actual ECMAScript object methods.

    2) Doesn't inherit properly in IE7/earlier on Node or descendants of Node such as Element

    As I don't care anymore about IE9/earlier (degrade to scripting off behavior since I actually have graceful degradation) and avoid official namespace issues by prefixing a double underscore... but I could have sworn there were more reasons not to do this.

    I just can't remember what those reasons were and my Google-fu is failing me miserably.

    It just feels like being able to say:

    Code:
    var escaped = myString.__htmlSpecialChars;
    is more convenient/sensible than REALLY polluting the global namespace with:

    Code:
    function htmlSpecialChars(str) {
    and...

    Code:
    var escaped = htmlSpecialChars(myString);
    Since it removes the value passage from it, as 'this' is hard-coded to the handler, removing extra stack manipulation.

    So... can anyone list out other problems with extending / morphing the browser system objects like String, Document, Node, Element, etc, etc?
    Last edited by deathshadow; Feb 6, 2020, 11:19 AM.
    I'll kill you and your dreams tonight, begin new life.
    Bleed your death upon me, let your bloodline feed my youth.
    https://cutcodedown.com

  • #2
    If you don't want to pollute the global namespace, then use your own (just as jQuery puts all its functions into the jQuery object/namespace).

    Given the example htmlSpecialChars() there is no need to use that as document.createTextNode() takes care of that already.
    The computer is always right. The computer is always right. The computer is always right. Take it from someone who has programmed for over ten years: not once has the computational mechanism of the machine malfunctioned.
    André Behrens, NY Times Software Developer

    Comment


    • #3
      Originally posted by Dormilich View Post
      If you don't want to pollute the global namespace, then use your own (just as jQuery puts all its functions into the jQuery object/namespace).
      I have that, I'm just not wild about passing around so much crap on the stack or returning a result that isn't actually the result. One of by biggest complaints about jQuery is how it returns jQuery's $ as a result for so many things instead of what you actually ask for. Leads to that derpy daisychain of $(something).do().something().else() that makes the code painfully difficult to read.

      Part of why I hate the annoying promise.then BS created for people too stupid to handle events properly, whilst making the code as painfully cryptic as possible.

      Originally posted by Dormilich View Post
      Given the example htmlSpecialChars() there is no need to use that as document.createTextNode() takes care of that already.
      Not if you want the escaped version shown in the text output... which I've needed on more than a few occasions. You can't actually extract what createTextNode creates escaped.

      Basically what if I have a PRE I want to show the escaped text in AS the escaped text?

      Element.appendChild(document.createTextNode(myString.__htmlSpecialChars));

      Because I want the ampersands and so forth to show in the ouput. Even more useful if you want to make a download of it.

      But that was just an example -- it could have been any of my methods.

      Really I'm more interested in why the technique is "bad", what drawbacks other than the two I listed are there? 'Cause if those are the only two, neither is sufficient reason not to do it... and it could REALLY simplify writing code that uses libraries if methods could just be attached where/as needed.

      Such as say an Element.__class where + is add a class, - is remove a class if it exists, and ! is toggle a class.

      Code:
      <div id="test" class="beta gamma epsilon">
      Code:
      var test = document.getElementById('test');
      test.__class = '+alpha -beta !gamma !delta';
      console.log(test.__class);
      Outputs "epsilon alpha delta"

      Just feels cleaner and more natural than:

      Code:
      _.classChange(test, '+alpha -beta !gamma !delta');
      console.log(test.getAttribute('class'));
      Using getAttribute as className doesn't exist on XML elements like SVG. It's just safer.

      ... and would consume less processing time since we don't have to pass the target object on the stack.

      Take something as simple as selecting a Node's content.

      Code:
      Node.prototype.__select = function() {
          var tempRange = document.createRange();
          tempRange.selectNodeContents(this);
          var tempSel = window.getSelection();
          tempSel.removeAllRanges();
          tempSel.addRange(tempRange);
      };
      or a node walk with callback:

      Code:
      Element.prototype.__forEachElement = function(callback, deep) {
          var e = this.firstElementChild;
          if (e) do {
              callback(e);
              if (deep && e.firstElementChild) e.__forEachElement(callback, true);
          } while (e = e.nextElementSibling);
      };
      That latter one IMHO superior to:

      Code:
      _.forEachElement = function(target, callback, deep) {
          if (target = this.firstElementChild) do {
              callback(target);
              if (deep && target.firstElementChild) _.forEachElement(target, callback, true);
          } while (target = target.nextElementSibling);
      };
      Because "this" is always superior to passing an argument.

      I'm just trying to remember why this technique was considered "bad".
      I'll kill you and your dreams tonight, begin new life.
      Bleed your death upon me, let your bloodline feed my youth.
      https://cutcodedown.com

      Comment

      Working...
      X