From: Robert Klemme <shortcutter@...>
Date: 2007-05-15T20:00:05+09:00
Subject: Re: Why was the "Symbol is a String"-idea dropped?

On 15.05.2007 12:31, enduro (Sven Suska) wrote:
> Robert Klemme schrieb:
> 
>> On 15.05.2007 03:07, enduro wrote:
> 
>>> Or, in other words: if the decision to unify Symbol and String would
>>> have been taken at early stages of Ruby development, then the
>>> general usage would have adapted to this, and ...
>>> we might be happier with the result today.
>>
>> I am in no way unhappy with the way it is today. Strings and symbols 
>> serve different purposes although there is some overlap. I rarely feel 
>> the need to convert between the two.
> 
> I see.
> And I am quite surprised. Because judging from your online activity
> you seem to have some experience.
> Perhaps it is also my programming style: I may use symbols where one
> normally would use strings.

Yeah, maybe.  So where are you using symbols where one normally would 
use strings?

>> I am not aware of a situation where you would need to mix them as hash 
>> keys. And to make the distinction is pretty easy most of the time IMHO.
> 
> Not aware? I mean Rails mixes them, right?

I don't use Rails. :-)))

>> Frankly, I believe there is an inherent advantage that you can use 
>> symbols vs. strings in code. And I mean not only performance wise but 
>> also readability wise.
> 
> Readability-wise: precisely what advantage?

If I see a symbol being used as a Hash key I immediately know (or rather 
guess) that there is only a limited amount of them and they are known 
beforehand, like with options.

# silly example
opts = {
   :length => 12,
   :width => 30,
}
# other code
resize( opts[:length] )

Whereas when strings are used it's typically stuff that is read from 
somewhere, like (another silly example):

ruby -aF: -ne 'BEGIN { $c=Hash.new(0) }; $c[$F[1]]+=1; END { $c.each 
{|k,v| print k, "=", v, "\n"}}' /etc/passwd

> The only thing that comes to my mind just now, is
> that a separated Symbol class easily provides
> distinct special values for a parameter that would normally carry a String.

Don't forget the optical distinction between using 'string', "string" 
and :symbol.

>> Note though, that all these issues have nothing to do with the question
>> whether String and Symbol should be connected inheritance wise. IMHO 
>> that's mostly an implementation decision in Ruby.
> 
> Yes, I agree.
> I am actually interested in the implications for the programmer.
> My original question just arised out of the notion
> that this implementation decision could have been a move
> in a (to my mind) favourable direction.

As we all have different habits what may be favorable for one may be 
regrettable for the other. :-)

>>> Yes, I sometimes think of that separation of Symbol from String
>>> as a tiny impurity in the Ruby crystal.
>>
>> Personally I believe it creates more expressiveness. If you view this 
>> as impurity, there are a lot of them in Ruby because Ruby's focus
>> has always been on pragmatism and not purity
> 
> 1.  The  core structure must of course be large enough,  and a  large 
> structure may  look impure.

This somehow reminds me of 
http://en.wikipedia.org/wiki/G%C3%B6del%27s_incompleteness_theorem

> 2.  But regarding this particular question: My original notion was that 
> keeping
>     Symbol and String too separate is not pragmatic.
>     (I may change my mind on that, if I read more posts like yours, 
> though.)

Just reread mine a few times - then you don't need the other postings 
any more.  That's more efficient - you'll save bandwidth and reading is 
actually faster if you know the text already.  :-))

>>> So, I'll just have to come to terms with it. :-)
>>> (And I will, of course -- there are enough other fascinating 
>>> issues... :-) )
>>
>> The capability to adjust to reality is a useful one IMHO. :-)
> 
> Well, yes, sometimes I'm glad someone tells me that. :-)

:-))  No sweat - following visions is useful as well.  As always it's 
the mix...

>>> create a class hierarchy similar to the Float/Integer hierarchy?
>>> String < Stringlike
>>> Symbol < Stringlike
>>
>> Why not?  StringLike could even be a module that relies solely on [] 
>> and length to do all the non mutating stuff.
> 
> Ah, interesting. Can't follow the implications right now.

For example regexp matching might be implemented similarly for both 
(i.e. just in one place).  But then again, since RX functionality is 
highly integrated into the language that might not be a good idea - or 
the C code needs to become more complex to react differently if it sees 
a String or Symbol vs. some custom class that includes this module.  Hm...

>> Given the fact that I don't mix symbols and strings as Hash keys I 
>> wouldn't benefit -
>> but it would not hurt me either. :-)  YMMV
> 
> Yes that was the idea behind it: to benefit some and not to hurt the 
> others.

The next best thing to a win win situation. :-))

>> Credits also go to the community that is still among the most 
>> civilized online communities I know so far!
> 
> Indeed, I'm experiencing it right now!
> Thanks a lot!

You're welcome.  Thank /you/!

Kind regards

	robert