02 July 2007
More often than not my solutions will involve heavy use of the Prototype.js library to make my life a little bit easier.
I won’t be shy, I love this library. I love that it isn’t based on XPath, and I love that it provides me with common extensions to common objects to make my life easier. It would seem, however, that there are quite a few people who disagree with me.
I’ve got to say, I’m quite surprised at the number of times I hear the arguments presented in this post.
To be honest, I don’t really understand what the problem is.
I’ve read through the article, and it’s the same argument I keep hearing over and over again.”Because prototype extends objects with new functions using the prototype attribute it breaks everything!”
This is not necessarily true, and has bordered on a religious war for a while now. :p
Prototype is doing nothing out of the ordinary.
Unlike class based languages, a prototyped language stresses the reuse of objects through cloning as opposed to stressing the relationships between created objects (If my memory serves me correctly).
Now I’m not arguing that “we should do it because we can”, but rather that as of yet, the Prototype developers have not extended any functionality, as of yet, that is already defined in native code in the browsers of today.
“I created a namespace for my code called OMGMyLongNamespace but SuperCoolBuzzWordFilledPackage2. 0 uses the same namespace and now they conflict and won’t work! They’re bad! Bad bad bad!”
Namely, if you want to use an associative array, use an Object. If you want to use an array then you should… I don’t know… use an Array?
Here’s an example. Which works as expected with Prototype.
var a = new Array(); a["joe"]=1; a["jim"]=1; a["sara"]=1; for( i in a ) if( a. hasOwnProperty(i) ) alert(i);
In short, I’d say prototype is doing just fine. So long as you develop smartly you shouldn’t run into any serious problems.