20 Responses to “On modifying prototypes of JavaScript built-ins”

1. Chris Double Says:
   May 23rd, 2006 at 9:35 am

   Good post. I agree that the issue with retrieving built in properties from the prototype is not a big issue. It is an issue in the specific case of using an object as a general hashtable where any string key can be stored, retrieved and queries from unknown input. Which is the case in code I’ve inherited, and has been broken due to not using hasOwnProperty, or overwriting methods stored in the object. It basically boils down to ‘understand what you are doing, why you are doing it, and the effect that it will have, before you do it’.

2. Justin Palmer Says:
   May 23rd, 2006 at 10:46 am

   I’m going to assume your talking about the Prototype library, not really sure why people avoid calling it by it’s name. If I’m wrong, forgive me.

   I would say no to modifying Array.prototype, if and only if you didn’t also provide a replacement for iteration mechanisms like for..in. Prototype however provides an iteration mechanism which pretty much (I haven’t found a case where I need for..in for Arrays) eliminates the need for for..in in conjunction with Arrays.

   Touching on the sparse arrays, this works fine in Prototype:

   var foo = new Array();
   foo[3] = ‘bar’;
   foo[7] = ‘more bar’;

   console.log(foo.without(undefined));
   console.log(foo.findAll(function(item) {
   return item != undefined;
   }));

   Both of these get you back all the items that are not undefined.

   I agree that if you modify the prototype of Array it has a risk of breaking other libraries, but shouldn’t this be left up to the person using the libraries to determine if they’re compatible? I could argue that the hood of my wife’s car, won’t bolt on to mine, even though both cars share a common purpose.

   I feel that if you use something created by someone else you have to subscribe yourself to a set of principles set forth by the creator. You have to learn the conventions. Prototype is popular for a reason, admittedly some of this popularity is due to the fact it’s bundled with Rails, but it’s reach goes way beyond that.

   - Cheers

3. David Lindquist Says:
   May 23rd, 2006 at 10:47 am

   Points well taken.

   But as long as we are forbidding things, I would much rather discourage the use of for/in than get rid of the über-handy Array enxtensions! Lord knows I have written my share of code that extends Array, and am just trying to assuage my guilt. :-)

4. Leo Says:
   May 23rd, 2006 at 11:50 am

   I am relatively new to serious Javascript programming, and I don’t understand this post completely. If I extend Prototype with some custom function I’ve written for my purposes, will it necessarily interfere with the in operator, or are we just talking about the fact that there are extensions of Prototype that COULD potentially do so?

5. David Lindquist Says:
   May 23rd, 2006 at 12:03 pm

   Leo,
   You are confusing (understandably) the Prototype framework with the prototype inheritance mechanism of the JavaScript language itself. Extending Prototype (the framework) is no problem. Entending JavaScript’s built-in objects using the prototype property is the issue here.

6. liorean Says:
   May 24th, 2006 at 1:30 am

   Justin: You’re assuming that the choice of using a library always belongs to the current programmer. Well, what if the programmer is not alone on the project? What if the programmer is taking over the project from another programmer? What if the problem lies in that the programmer can’t combine two libraries without having to rewrite one of them to accomodate the other?

   Over all when writing a library, modifying prototypes of built-ins — at least when those built-ins are Object and Array — is something you should avoid, because your library might break other libraries or your users’s code.

   Also, don’t assume asking for whether a member is undefined is the same as asking for whether the member exists. I have written code where you can find tests like these:

   if(s in o&&undefined===o[s])
       codeForWhenMemberExistsButIsUndefined();
   

7. Justin Palmer Says:
   May 24th, 2006 at 8:19 am

   liorean: That doesn’t fall on the creator of a library. It’s up to the working team to evaluate libraries they do or don’t want to use. If Bill and Jane don’t think Prototype or other libraries which modify the .prototype of built ins are suitable for their project, they shouldn’t use it. It won’t be everything to everybody, nor does it pretend to be. It’s like I’ve said before, you either love it or you hate it, but if you want to use it, you have to accept it along with it’s philosophy.

   I completely agree with you about Object.prototype, but not Array.prototype. Prototype was *designed* to be an extension of Javascript, not a framework that sits on top of it. It makes Javascript better for 80% of the people that deal with *every day* problems.

   If a programmer is taking over a project from another, he/she will always be faced with constraints. I think the scenerio of clashes in Javascript will be the least of his/her worries. That person should be griping at the programmers that used to be on the project for choosing something like Prototype. Prototype doesn’t hide the fact it modifies built-in objects.

   On your last point, fair enough. It was a quick example to show it could be done. It could be easily rewritten to do a complete check.

   –Cheers

8. Dustin Diaz Says:
   May 25th, 2006 at 3:58 am

   Good thoughts. However I’m going to keep my Array.prototype.inArray(needle). But then again, I am generally the sole person in a project when that gets used.

   Any thoughts on extending Function.prototype as well? Drawbacks, caveats?

9. Erik Arvidsson Says:
   May 25th, 2006 at 12:42 pm

   If sparse arrays is the only argument for not modifying Array.prototype at least you have convinced me that it is acceptable.

   The only property Array has that Object does not is the magic length property and in the few cases where a sparse array is needed object and manually keeping track of the length seems good enough to me.

   Like I said there is nothing except the magical length property that makes an array an array (as well as the array literal syntactic sugar and the prototype). Even the methods on Array.prototype are generic enough to work on any mutable object that looks like an array:

   var a = {‘0′: 1, ‘1′: 3, ‘2′: 0, ‘3′: 2, length: 4};
   Array.prototype.sort.call(a);
   console.log(Array.prototype.toString.call(a));

   try changing a to [1,2,,0] as well as to {‘0′: 1, ‘1′: 2, ‘3′: 0, length: 4}.

10. Erik Arvidsson Says:
    May 25th, 2006 at 12:51 pm

    Oh, one more thing. The reason toString is not showing up in for-in loops and when using the in operator is an JScript bug.

    https://connect.microsoft.com/feedback/ViewFeedback.aspx?SiteID=136&FeedbackID=72707

11. liorean Says:
    May 25th, 2006 at 5:43 pm

    Erik: It should only appear in an enumeration if it was overridden — which is the case that bug is about. But I’m talking about the case where it’s not overridden – in that case, it will not be enumerated, because ECMA-262 3ed. specifies that it’s {DontEnum}. So, there’s no way of autodiscovering it in code. The problem is one of getting the property from the prototype when you in fact only wanted properties from the actual object. And for that, you only need to check whether it exists on the object at hand or not, which can be done using arr.hasOwnProperty(key).

    As for sparse arrays not being enough of a concern to avoid extending Array.prototype — maybe you’re right about that. It’s not a common use of arrays. I’m still of the opinion that libraries should try not to destroy native language functionality though.

    It’s not as if arrays and iterating over them is homogenously implemented anyways. Try this in moz, iew and op:

    var
        a=[,,,,,,,,],
        b=[],
        i;
    a[4]='first';
    a[0]='second';
    a[2]='third';
    for(i in a)
       b.push(i+':'+a[i]);
    p.push('length:'+a.length);
    b.join();

    Moz and iew have their bugs with sparse array literals. Op has a different — but entirely correct accoring to the spec — implementation of the iteration through array members. Or rather of how those members are stored, but it amounts to a difference in the iteration.

12. Hermann Klinke Says:
    May 30th, 2006 at 5:06 pm

    I do not understand you problem with extending Object.prototype. You can still iterate over its members as you did before by ignoring the members of Object.prototype.

    for (member in object)
    {
    if (Object.prototype[member] === undefined)
    {
    //do your thing
    }
    }

13. liorean Says:
    May 30th, 2006 at 5:36 pm

    Hermann: Yes, you can. But you’re repeating the error I talked about with regard to the Array prototype, but in larger scale – by extending Object.prototype you are forcing everybody else to do that runtime checking for every object whose members they want to iterate through. You’re breaking all code that didn’t do that checking because they knew that all built-in members are marked {DontEnum}. Breaking language built-ins is bad, because you’re breaking code that normally would work perfectly fine. Any solution to the problem that would demand changing other code is unacceptable.

14. Hermann Klinke Says:
    May 31st, 2006 at 4:18 pm

    I see your point. Thanks for the clarification!

15. Andrew Dupont Says:
    June 8th, 2006 at 4:57 pm

    Liorean, this is a good post, and I wish I had happened upon it sooner. I started to post a comment, but it turned into a theological tract, so I’ll just link it here. Cheers.

16. Dean Edwards Says:
    June 9th, 2006 at 7:04 am

    I really disagree with this post. It is arguments like this that hold back JS development. None of the reasons you come up with have convinced me that extending the Array object is a bad idea.

    In one of your code samples you use the example of Array.push. IE5.0 does not support this. How do we get our code to work with IE5.0? We extend the Array object of course.

17. Mike Says:
    June 12th, 2006 at 10:50 am

    You wrote:
    “using a normal for(i=0,l=a.length;0>l;i++) loop”

    Shouldn’t this be
    for(i=0,l=a.length;l>i;i++)

    ??

18. Thomas Frank Says:
    June 15th, 2006 at 10:54 pm

    I really disagree too. Prototypes are an important part of JavaScript. It’s not the programmer who extends them that is sloppy – it’s the programmer who won’t check if they’re extended. It is really easy to check this:

    //let’s extend another prototype
    String.prototype.proto=function(obj){
    var proto=obj.sort?Array.prototype:Object.prototype;
    return proto[this] && proto[this]==obj[this]
    };

    // and extend some more prototypes
    Object.prototype.you=1;
    Array.prototype._dont=1;
    Object.prototype.like=1;
    Array.prototype._this=1;

    // and create a new array
    var x=[1,1,1];
    x.you=2;

    // now it is really easy to iterate through non-prototype members
    // this will return 0,1,2,you
    props=[];
    for(var i in x){
    if(!i.proto(x)){
    props.push(i)
    }
    };
    alert(props.join(“\n”))

19. Thomas Frank Says:
    June 15th, 2006 at 10:57 pm

    Sorry didn’t get my pre tags right ;-):

    
//let's extend another prototype
String.prototype.proto=function(obj){
var proto=obj.sort?Array.prototype:Object.prototype;
return proto[this] && proto[this]==obj[this]
};

    // and extend some more prototypes
    Object.prototype.you=1;
    Array.prototype._dont=1;
    Object.prototype.like=1;
    Array.prototype._this=1;

    // and create a new array
    var x=[1,1,1];
    x.you=2;

    // now it is really easy to iterate through non-prototype members
// this will return 0,1,2,you
props=[];
for(var i in x){
if(!i.proto(x)){
props.push(i)
}
};
alert(props.join("\n"))


20. Daniel Phillimore Says:
    November 18th, 2006 at 8:15 pm

    In response to that last post, all I do to skip extended members is as follows (untested, conceptual):

    Array.prototype.extender = window.alert; //random reference
    var arrArray = ["foo", "bar", "chicken"];
    for (var anyIndex in arrArray)
    {
    //skip extension
    if (anyIndex != “extender”) continue;

    //…

    //do_something…
    }

Leave a Reply