Hello everybody,
Although not a lot from the Ruby-Core specialists,
but still I have learned a lot from the discussion.
I am trying build a conceptual picture now.
Some say Strings and Symbols are conceptuelly very different
some say they are quite close.
I view it like this:
Symbols essentially are names, Strings essentially are data,
while they both appear as sequences of characters.
Names/Symbols are just atomic, constant, unrelated entities,
while Strings as data have a rich life, they can be related in
many ways they can be analysed, even be modified.
That's a clean distinction and I think it is very well-represented
in the current Ruby implementation.
It this light, it seems nonsensical to make one the subclass of the other.
(A common superclass would be OK, though.)
Now, in practice, the situation gets more complex:
1. Names sometimes turn into data (option names, method names, table names...),
especially when things get highly dynamic.
2. Sometimes, programmers to use the conceptually "wrong" class, maybe
as a kind of optimization, for the sake of beauty or out of lazyness ... 
One could argue that it is good that Symbol and String are well-separated,
because it educates programmers to decide for the "correct" class to use.
On the other hand, the following situation occurs very very often:
You need to transfer a sequence of characters -- which format do you use
always Symbols, always Strings, should it allow both? (Or even a fancy object)
First, you could argue that when you use duck-typing, the interface can be kept open.
But still, many situations remain, where this question is remains.
This choice can be a burden, especially if you think of inter-operability or optimisation.
And that is an argument for some sort of unification of Symbol and String.
Subclassing alone would not be enough, to solve the problem above,
also, String#== and Symbol#== would have to be defined such that "a" == :a
And also #hash would have to be defined accordingly.
Then you would still have the two different kinds of objects ("a" and :a)
but they would behave quite the same except for modifying methods.
Now, as I am writing this, I doubt that the advantages
of the unification are really worth doing it...
It depends on factors not known to me.
But now, I think I can understand the core-team's decision better.
Bye
Sven
Brian Candler schrieb:
···
On Wed, May 16, 2007 at 12:23:09AM +0900, Gary Wright wrote:
On May 15, 2007, at 10:53 AM, Brian Candler wrote:
Yes, but it's not a singleton.
You've stated or implied a couple of times in this discussion that
symbols are 'singletons', but I thought the conventional definition
of 'singleton' was of a class with only a single instance, where the
instance is called a singleton. That doesn't describe Ruby's symbols.I think what you are getting at is the idea that identity and
equality are one and the same for symbols.
No, that's not exactly what I meant, but sorry for not being more precise.
What I meant was: there is only ever one symbol object in existence for a
particular sequence of characters. :foo.object_id in one part of the program
is always the same as :foo.object_id elsewhere.If it were Symbol.new("foo") always returning the same object then I guess
it would probably be called the multiton pattern.
Isn't the term "immediate value" used for that? Like:
:abc is an immediate value, and so is 12, so is nil
"abc" is a reference value und so is [1, 2] and also {} and even 12.0
