On 5/15/07, enduro <sven715rt / suska.org> wrote:
> 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
> ruby-core team.
I really have not taken offense. However if you are interested in that
only you might post to ruby-core only.
I am kind of surprised that the considerations of Rick and YHS are
considered as OT.
If you do not like them maybe it would be polite to ignore them. But
talking about the topic on *this* list and ignoring all background
information about what symbols are and have been is kind of weird.
Please remember that Ruby has its inheritance in other languages
owning symbols as I believe to have pointed out.
The fact that the original idea is a big paradigm shift does not
answer your question?

I honestly do not understand that.

Threads just evolve I do not feel that they belong to OP :).
They do not belong to me either of course ;).
Cheers
Robert

>
> And I was indeed enlightened by matz's answer:
>
> >On May 13, 12:07 pm, Yukihiro Matsumoto <m... / ruby-lang.org> wrote:
> >
> >
> >>Hi,
> >>
> >>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:
> >>
> >>|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
> >>|well.
> >>
> >>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.
> >
> >T.
> >
> >
>
> 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.
> Kind regards,
> Sven
>
>


-- 
You see things; and you say Why?
But I dream things that never were; and I say Why not?
-- George Bernard Shaw