Why are symbols not frozen strings?

Question

I understand the theoretical difference between Strings and Symbols. I understand that Symbols are meant to represent a concept or a name or an identifier or a label or a key, a

Answer 1

The basics of it are, these should not be true:

:apple == "apple"  #=> false, should be true

:apple.hash == "apple".hash #=> false, should be true

Symbols are always the same objects, and text is not.

Answer 2

See this answer: https://stackoverflow.com/a/6745253/324978

Main reasons: performance (symbols are stored as integers, and are never garbage collected) and consistency (:admin and :admin will always point to the same object, where "admin" and "admin" don't have that guarantee), etc.

Answer 3

Another consideration is that "apple".each_char makes sense, but :apple.each_char doesn't. A string is an "ordered list of characters", but a symbol is a atomic datapoint with no explicit value.

I'd say that HashWithIndifferentAccess actually demonstrates that Ruby symbols are fulfilling two different roles; symbols (which are essentially like enums in other languages) and interned strings (which are essentially a preemptive optimisation, compensating for the fact that ruby is interpreted so doesn't have the benefits of an intelligent optimising compiler.)

Answer 4

This answer drastically different from my original answer, but I ran into a couple interesting threads on the Ruby mailing list. (Both good reads)

So, at one point in 2006, matz implemented the Symbol class as Symbol < String. Then the Symbol class was stripped down to remove any mutability. So a Symbol was in fact a immutable String.

However, it was reverted. The reason given was

Even though it is highly against DuckTyping, people tend to use case on classes, and Symbol < String often cause serious problems.

So the answer to your question is still: a Symbol is like a String, but it isn't.
The problem isn't that a Symbol shouldn't be String, but instead that it historically wasn't.

Answer 5

If at all a String could inherit Symbol, because it adds a lot of functionality (mutating). But a Symbol can never be used "as a" String because in all circumstances where mutation would be needed it would fail.

In any case, as I said above, string == symbol must never return true as has been suggested above. If you think a bit about this you'll notice that there can be no reasonable implementation of == in a class which considers sub class instances as well.

Answer 6

I don't know about a full answer, but here's a big part of it:

One of the reasons that symbols are used for hash keys is that every instance of a given symbol is exact same object. This means :apple.id will always return the same value, even though you're not passing it around. On the other hand, "apple".id will return a different id every time, since a new string object is created.

That difference is why symbols are recommended for hash keys. No object equivalency test needs to be done when symbols are used. It can be short-circuited directly to object identity.