Thank you all for your replies.
And thank you, Xavier, for keeping the focus on my original intention.
Yes, I was not asking about general arguments for designing a class
hierarchy, but for the reasons for this particular decision of the
And I was indeed enlightened by matz's answer:
Just wanted to point out that the original question is why Ruby core
changed their mind, not what people think in general about relating
String and Symbol. Perhaps the question could be sent to ruby-core as
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.
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.
At least, that is my private opinion on this question:
It is tempting to say: "Symbols are just integers internally,
they are just isolated points in 'Symbol-space',
so it is not suitable to give them string methods."
But I think in practice this is not true:
- Symbols are a standard data type for meta-programming
(and immediately, there will be a need to append a "?" here and then,
or test for some regexp-condition...)
- 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).
Yes, this gives us programmers the freedom to optimize the code...
(... but I think a standard solution would serve better in most cases.)
Yes, I sometimes think of that separation of Symbol from String
as a tiny impurity in the Ruby crystal.
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.
So, I'll just have to come to terms with it.
(And I will, of course -- there are enough other fascinating issues... )
Along the lines of Trans:
That's unfortunate. IMHO it's generally bad practice to functionally
differentiate between them. But this being the official status now, I
don't see any reason to accept string hash keys for method options
anymore. It's just not worth the extra code and computation to do so.
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
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.)
Anyway, I'd like to thank the core programmers for all the work
they have put into Ruby to make it shine.
On May 13, 12:07 pm, Yukihiro Matsumoto <m...@ruby-lang.org> wrote:
In message "Re: Why was the "Symbol is a String"-idea dropped?" >> on Sun, 13 May 2007 17:20:49 +0900, Xavier Noria <f...@hashref.com> writes: