Support for Ruby-style symbols about coffeescript HOT 10 CLOSED

The thing I like about symbols (other than the performance advantages) is that they somehow feel less like "magic constants". For example, in C people hate seeing things like:

int rate = 42;

They want to know "what the heck does 42 mean", so we tend to say:

#define STANDARD_FALL_RATE 42

int rate = STANDARD_FALL_RATE

I consider this to be a problem with strings as well. Let's say I have some control variable:

mode = "Normal"

That string bothers me because it implies that I can put anything there and there's some magic list that's going to check what I put in there against the list. You can make it more explicit by saying:

 mode = :Normal

This implies that, although it is a string, it is a string that's SEMANTICALLY RELEVANT to the code-base.

from coffeescript.

hmm, why?

from coffeescript.

Ditto to jnicklas's question. What would this become? Compile symbols into globally-unique integers, or something like that?

from coffeescript.

javascript strings do not behave like ruby's strings; javascript has immutable strings where ruby does not. Ruby's symbols are immutable in part to meet the need for immutable string-like identifiers.

seriously though, try this in IRB:

irb(main):001:0> "foo".object_id == "foo".object_id
irb(main):002:0> :foo.object_id == :foo.object_id

Javascript doesn't have the same problems this implies with ruby strings.

from coffeescript.

Strings might be immutable in javascript, but comparing them is still more expensive than comparing integers. Here's a test (in Safari):

Still, the speed difference isn't so great that we need to add symbols to CoffeeScript.

from coffeescript.

Just wanted to add that I can certainly see not adding this to the language. I'm not sure that symbol support would pass your "unfancy" directive.

from coffeescript.

You make some very good points. Unfortunately, there's a critical wrinkle that pulls the rug out: You wouldn't be able to use symbols as keys in JavaScript objects (hashes). That's one of their primary uses in Ruby, and without it, there's not enough advantage to justify a new language concept. In addition, you wouldn't be able to meaningfully serialize them into JSON.

This is a good discussion to have on the record. Closing the issue...

from coffeescript.

Really a symbol is just an immutable string without spaces (in most cases), so you could just represent them as strings, but disallow allow certain operations on them. Whether it's worth it is another question...

from coffeescript.

I agree that symbols - if implemented - should simply be strings without certain operations. It's more about syntactic clarity and not as much about performance. In places where you would currently use a string from a preset number of possibilities, such as the eventName in a bind operation, readability would benefit from using a symbol instead of a general purpose string.

from coffeescript.

Symbols could be compiled to strings. Example:

:comments is 'comments'

:comments becomes 'comments' in compiled JS.

from coffeescript.