To use an example: a few comments ago, someone linked to a blog post that noted its author’s inability to get Prototype and TinyMCE to work on the same page. Investigation reveals that this conflict is caused by TinyMCE’s improper use of Array with string keys. (TinyMCE is otherwise excellent, so it goes to show how common this mistake is if such a robust tool employs it.) I’ve filed a bug on TinyMCE’s SourceForge project, and since the fix is so simple I hope it’ll get done soon.

If there are those who still think that using string keys in Arrays is a valid practice and should not be discouraged, they ought to read my recent article on this topic: JavaScript “Associative Arrays” Considered Harmful. It makes an exhaustive argument, one far too long to fit in this comment.

Over’n Out on this post.

More importantly, debugging javascript interdependencies of this type is a nightmare. Semantic nitpicking about how certain code is wrong is little consolation for the developer who’s code works without Prototype, but breaks when Prototype is included.

/*
I

It flys in my real world environments just fine. Then again, everything is built in from prototype 8P.

You seem to be arguing from the position that the two are obviously one and the same, and that the burden is on me to convince you that they ought to be separate. Again, I ask: what advantage is there to using Array instead of Object, other than your argument from linguistics?

Out of curiosity, if modifying Array.prototype (or any other object’s prototype) is such a horrid idea in the first place, then why is it explicitly allowed by the language? (Also: the $ function has nothing to do with any object’s prototype; it’s just an ordinary function. Should defining functions be considered “bad practice”?)

Yes, I know the point your trying to drive home, in short “Everything is an object so its not really a hack because its the same as array”, this is what I meant by “behind the scenes”…. behind the scenes an array is just an object that your free to have your way with and (insert your previous post here…). Yes I know this, but when it boils down to it, we do have an “array type” and we can insert custom keys, making it the very definition of the technical term “associative array”. Javascript, like every language out there, has a thousand differen ways to mimmick associative arrays. Regardless, considering the very definition of associative arrays, and the fact that we do have an “array type” makes it a feature. As far as I’m concerned, the javascript “authority” is the existing code base that people (in a real development position, not just hobby) use. You cant go messing with the prototype because your too lazy to type document.getElementById(”), and then yell at the authors of the scripts that you just broke saying “your doing this wrong…”. We’ve had people do this, adding $, or adding additional functionality, and consequently breaking 5+ years worth of code. Its caught in testing, and they are forced to code the right way. With that said, for small independantly developed stuff that isnt going to be reused, or as a free standing little project, by all means, use $

It is true that in a pristine browser enviroment, the code below will behave exactly as you would expect:

var arr = new Array();
arr["one"] = 'one';
arr["two"] = 'two';
arr["three"] = 'three';
for (i in arr { alert(i); } // (or your logging method of choice)


What’s also true is that the above code works even when you replace Array with RegExp, Date, String, or Boolean. I know because I experimented just now.

All these objects “work” as hash tables because they’re all children of Object. That doesn’t mean that using them this way is correct, and it certainly doesn’t mean that the prototypes of these objects are hands-off. Most importantly, though, there’s no advantage whatsoever in using Array over Object, so I don’t understand why using Object is the “hack” and using Array is the “feature.”

I can’t believe people can’t see that its a mis’use of the Array. When you do var foo = new Array(); foo['apple'] = 3, you havent added anything to the array. You have just assigned the foo array object a property named ‘apple’ and = to 3. In other words alert(foo.apple); //returns 3.

Come on now.
var foo = new Object(); foo['apple'] = 3; //woah I have an associative object *snicker*

whoa whoa whoa, sorry but this comment is wrong

I’m guessing you’re trying to use the Array object with string keys, which doesn’t work, and is incorrect.

Associative arrays are a feature, just because the way they where origionally implemented behind the scenes is unusual, does not make it ” incorrect ” to use. The dollar sign stuff is a hack, the object workaround for associative arrays is a hack, so there is no room to even begin saying that using associative arrays in the classical sense in js is wrong.

I think it’s a good thing that there are major design differences between Dojo and Prototype — it means that the two are not really in direct competition. Choosing between them isn’t necessarily about which is ‘better’; it’s about which one fits your brain better, and that will vary from person to person. As a result, the competiton between the frameworks is healthy rather than combative (in my opinion). (I think Alex even said something to this effect at the Ajax conference, in contrast with the gruff exterior he sometimes casts on the web. :)

Though I hack Prototype in my spare time, I have no formal affiliation with the project, but I’m active in its informal support mechanisms, and I think it’s a great idea to collaborate on the big-picture stuff. Why don’t you shoot me an e-mail (just follow the link to my site) and we can discuss it further?

I think Alex has grown up a lot over the past year. I think if/when you meet him, you’ll realize he’s passionate about his work, and sometimes outspoken about it. That said, most dhtml hackers tend to be miserable :), and we’ve all said stuff in our lives that we would prefer to take back

I do know that when prototype was first released, several of the Dojos were upset, not because of what prototype was, but for two reasons: 1) yet another toolkit (Dojo was started through bringing together 4 existing toolkits, and a number of old school dhtml hackers), and 2) we were way too slow getting an initial release of Dojo out the door, losing the chance to provide something you all could build on top of (probably because so many strong personalities were coming together at once and trying to agree on something :) ). For me, I feel bad when good people suffer through some of the mistakes I’ve suffered through already.

I think the adoption of prototype and its derivatives has been amazing, as has the adoption of Dojo and the other leading toolkits. I’m still in awe of the interest in what we are all trying to do here. I think healthy co-opetition (for lack of a better term), along the model of what Opera/Safari/Mozilla, is great for raising the quality of all of our toolkits.

We all suffer through documentation woes, because people want to work on features and bug fixes, not docs. And of course, we all have the problem of docs quickly becoming outdated when code changes as rapdily as it does with the current pace of toolkit development. We’ve been working on a
documentation tool that we hope many toolkits can use as a starting point for docs.

If you are interested, we would be more than willing to work with you all to increase interoperability, define common APIs, collaborate on development tools, etc. … anything that might make life easier for the bigger development community, and stuff that might encourage people to use existing toolkits rather than starting from scratch. And of course we’d want to do that in a way that had a high signal to noise ratio.