This is the main problem I have with it; it's a very dynamic language but in a totally dangerous way. It should hash based on an object's identity or something; as it stands, there's no way to do that in JS without bolting your own junk on top, as a result you can't do real object<->object associations in JS.

Python for example has well-defined and useful behavior when you shove something into a dict type as a key, for strings it will hash based on the string value, for some other things it will uses identity, etc., and you can overload it (which you can in JS too of course, as you showed.)

Your use case is not something I've ever needed to be honest, and if you need it, it's simple to build it out yourself. For example, in an object constructor, just replace the toString() to return a unique ID for that object. A line of code :/

It's only dangerous when you don't understand what is happening. Why didn't you research why your image example was confusing you? As I say, read the book.

This gives us an equivalent mapping, but unfortunately it alters the original object by adding a property to it. This sucks for two reasons; one is that the names might clash with a property that something else has set on that object, so you end up creating terrible names to avoid collisisions like someObject._prviate_associatedOtherObject or something, and then you have to make sure to destroy it when appropriate. It gets more hairy if you need multiple relations between the same objects. The other problem is that when you enumerate an object, now that property will show up. Gross. Yes, I know about the boilerplate you use to make enumerations in JS safe; my argument is that JS sucks as a language, and the necessity of stuff like this contributes to it.

For example, in an object constructor, just replace the toString() to return a unique ID for that object. A line of code :/

The Cappuccino/Objective-J guys at 280North have to do something similar (grep for OBJECT_COUNT++ in the source to see what I mean) in order to add identity to Obj-J objects.. but what if you didn't instantiate the object yourself? And I think this is the case where you'd be most likely to want to perform a mapping on an opaque object.

Well here's an example, I have an AJAX instant messenger app. Due to the protocol it talks on, multiple users may have the same name (a reasonable request, I think.) When a contact on a user's buddy list connects, the JS library in charge of talking to the server passes an opaque ChatUser object (or whatever) to any registered callbacks. So, I write a second set of JS stuff to manage the GUI, like the window for the buddy list, etc., and register it to receive the callbacks from the protocol manager. When I get a user that connects, for example, I should probably create an html span with that user's name and away status in the div that holds the buddy list.

Now, when a buddy changes his/her away state, the protocol manager will tell the registered callbacks that a ChatUser has changed status (or you can register for a callback on the ChatUser object itself, either works.) We need to change the status message in that user's span. But how do you find the span we need to modify? The ChatUser object is mostly opaque except for a few documented calls we can make on it (getName, getStatus, etc). Setting new properties on it is probably a bad idea, since we don't know what the original library is going to be doing with it.

In another language you can just associate the span's identity with the ChatUser through a map or dictionary. But you can't associate based on identity in JS, so you're left setting some crazy property on the ChatUser instance and hoping it doesn't collide or cause problems. We can't base it on the ChatUser's name, because what if there are multiple Joe Browns in the contact list?

It's a contrived example, but I hope it illustrates the importance of associations. There are multiple workarounds for this situation. But they aren't elegant, which is why I think JS sucks :]

  1. You would keep a pointer to the span, in each ChatUser object.
  2. You would have *some* unique ID passed from server->client
     to identify which user its talking about. A session ID say.
     this could be used to lookup the ChatUser object.

Nope, and I actually think your proposed method - mapping ChatUser->span is incredibly ugly and inelegant. Horrible design. A ChatUser object should know what UI elements it is in control of directly.

Most? The minority I'd expect. Others do things like

    TypeError: unsupported operand type(s) for +: 'dict' and 'int'

What Axod perhaps should have said is "most languages that support automatic type coercion."

We could have a flamewar all day about whether or not type coercion is a good or bad thing. And, actually, tumult's whole complaint could be summed up as type coercion is bad, and I don't get that object literals are different from string literals.

Many languages with type coercion, where objects can be converted to a string via a toString method of some sort, behave the same as Javascript. At most, like php, they log a warning or notice of some sort.

Personally, I prefer type coercion to throwing errors, and I prefer loose types to static types. Apparently, tumult doesn't, to the point of whining about the programming language that is the lingua franca of the web. To each his own.

awk and perl handle "foo" + 12, but they coerce "foo" to an integer, which is 0, and then add 12.

(Note, C lets you do "foo" + 12 but it isn't coercing 12 to a string, instead it's adding 12 to the address of the string "foo", e.g. "0123456789abcdef"[nibble].)

It would be interesting to enumerate those that do treat "foo" + 12 as if it was written "foo" + "12".

Edit: add http://en.wikipedia.org/wiki/List_of_programming_languages