On 15.05.2007 03:07, enduro wrote:
>>> We once changed Symbol as subclass of String to see how it goes, and
>>> met many compatibility problems.  People distinguishes Symbols and
>>> String far more than we expected.  So we just abandoned the idea.
>>>   
> This tells me, that it was mainly the weight of the existing ruby usage,
> that flipped the balance towards the conservative side.

Which is not a bad thing in itself.

> 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.

> - Symbols are fast as Hash keys,
>  but the "real-world" keys often are strings, or even can be both,
>  and then the current situation creates the well-known dilemma
>  to decide for a Symbol/String interface (and implement it).

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.

>  Yes, this gives us programmers the freedom to optimize the code...
>  (... but I think a standard solution would serve better in most cases.)

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.

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 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 (although it goes pretty far in 
some areas, for example it avoids the POD vs. object distinction that 
Java has (I would say this is a pragmatic decision because it makes 
things easier if you have a common base class for *all* types)).

> I thought Ruby 2.0 could have been a chance to iron this out.
> But it seems that now only small changes are still possible.

 From what I gather Ruby 2.0 will have some major changes, for example 
in the area of scoping.  Though it's probably done in a way that it will 
reduce the impact on existing programs.

> 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. :-)

> Before I close, just a small thought regarding the issue that
> subclasses are usually extended from their superclass, and not restricted.
> I don't know if that had been discussed before: would it perhaps be good to
> 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.

> Of course with everything set up such that hash[:a] is the same as 
> hash["a"] etc.
> (Just a thought, probably this already has been rejected.)

I'm not sure whether this is a good idea.  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

> Anyway, I'd like to thank the core programmers for all the work
> they have put into Ruby to make it shine.

Definitively!  Credits also go to the community that is still among the 
most civilized online communities I know so far!

Kind regards

	robert