From: Rick DeNatale <rick.denatale@...>
Date: 2007-05-13T01:41:27+09:00
Subject: Re: Why was the "Symbol is a String"-idea dropped?

On 5/12/07, Trans <transfire@gmail.com> wrote:

>
> There are a number of advantages to sub-classing that I can think of:
>
>   1)  No need to do x.to_s.some_string_method.to_sym

Well, let's see. Why do we do symbol.to_s ?

    1). When we want a string representation of the symbol so that we
can say mutate it.  Subclassing won't help here.
    2) If we want to compare a string with a symbol.  Making Symbol a
subclass of string alone won't do this, and if we change Symbol#== so
that :a == "a" is true we destroy one of big advantages of Symbols
which is the speed of determining that two symbols are equal based on
their identity, this is why, for example, symbols rather than strings
are used as method selectors.

And why do we do string.to_sym, primarily because we want the speed
advantages of symbols in comparisons.

>   2)  Hash keys could efficiently equate symbol and string keys (it's
> the distinction that should be optional)

No I think that we'd actually get the worst here, it falls out of #2
above.  Symbol hash keys are more efficient than String hash keys
because of identity.


>   3)  It's conceptually simpler: a Symbol is an immutable String.
   No it isn't. A symbol is an object with an immutable string as a
name, and which is the sole instance with that name.

Now an interesting idea might be to add more string methods to Symbol
so that for example one could do

   :a + :b #=> :ab

So that there was more of a Symbol algebra which was still closed so
that the results were still Symbols.

-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/