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:
- Names sometimes turn into data (option names, method names, table
names…),
especially when things get highly dynamic. - 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 C. schrieb:
of ‘singleton’ was of a class with only a single instance, where the
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
