| While not addressed to me, i'd like to chime in with some comments of my own here. One of my personal gripes with javascript as an environment is that out of the box there is exactly two composite data structures, and both are associative: Objects, and Arrays. As you are probably aware, Objects are the bread and butter of Javascript and double as full OO objects and also as map/dictionary types with the limitation of only allowing String keys. Arrays have their own quirks but lets leave that aside for now. Javascript lacks a well understood model of value identity[1]. Without a common model for value identity (i.e. more than reference identity) it becomes very difficult to implement custom data structures (e.g. a BTree for implement a true dictionary type) in a way that can easily (and naturally) be consumed by third parties. Lacking the ability to hook into the [] operator increases the awkwardness for anyone attempting to provide their own custom collections. I would suggest that the lack of good quality collections deployed widely in the javascript world underscores this problem. Contrast this with just about any other language you can think of and it is even more stark. As an example, any good language probably has a Set datastructure these days. There are two ways to fake it: Degenerate map with the key being the real value and either some sentinal (such as true) or the key itself as the value, or (as is very common in javascript) an array and then doing indexOf. Let that sink in: a common approach to sets in javascript (when you cant easily provide a string key for your object) is to do a linear search. Yuck. For a wonderful counter point, have a look at how ClojureScript implements its own collection types, complete with value identity, indentity partitions and proper maps with object keys. [1] Leaving aside all the unknowns most javascript programmers have about the `valueOf` method. |
Arrays? Secretly hash tables.
Objects? Well, yeah, them too.