From: Robert Dober <robert.dober@...>
Date: 2007-05-15T18:42:59+09:00
Subject: Re: Why was the "Symbol is a String"-idea dropped?

On 5/14/07, Trans <transfire@gmail.com> wrote:
>
>
> 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.
>
> 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.
>
I really like the idea of using symbols as parameter keys exclusively,
I think we would get closer to named parameters instead of emulating
them.
And the interesting stuff is, I always hated String keys in parameter hashes.
Does this go together with the fact that I really like the good old
Symbols are not Strings paradigm? Probably.

But right to now I fail to see what would be the gain from making
symbols mutable.
I still maintain the POV that immutable Symbols must not be a subclass
of String.

Any more thoughts?

Cheers
Robert
>
>


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