From: Trans <transfire@...>
Date: 2005-10-25T08:32:02+09:00
Subject: Re: String as Subclass of Symbol?


Eric Hodel wrote:
> On Oct 24, 2005, at 7:17 AM, Trans wrote:
>
> > Has it ever been considered making String a de-immutablized
> > subclass of
> > Symbol? Would this allow for a natural coersion of Symbols to Strings,
> > akin to Integer to Float? The above is a common enough occurance. And
> > in general I can't think of a signifficant occurance in which I needed
> > to distingusih a symbol from a string of the same basic value
> > (ie. :foo
> > and 'foo') for the same parameter. I suspect there really is no good
> > reason to ever do so --b/c if you are, you're doing something rather
> > tricky that probably should be done another way. Of course if anyone's
> > got a good counter example please share.
> >
> > Not that I've fully work this idea through, but I suppose the upshot
> > would be two fold:
> >
> >   1) Certain method could coerce symbol to string when deemed
> > appropriate,
> >      such a Hash#[].
>
> This is inappropriate behavior.  Attempting to mix strings and
> symbols for hash keys is bad design.  Pick one and stick with it.

Easy to say, but not so easy in practice. Often it is not just a matter
of catering to ourselves but to others, some prefer to use strings over
symbols and vice-versa. But more importantly consider the difference in
the system itself. #method_missing carries a symbol, yet
#instance_methods returns strings. One has to deal with such things in
interchange.

The idea I'm inquiring about here, is that perhaps symbols and strings
should not thought of as wholly separate things. The symbol is a string
but immutable and light-weight. Thus it is more suitable to certain
scenarios, such a keys. Strings are just symbols "upclassed", mutable
with a larger method set, hence for more veritile usage. In this way we
could see them more as "modes" of essentially the same thing. And I
think this may be a very useful way to percieve it, that potentially
could bring an end to the all too common:

  def (x)
   x = x.to_sym

or

  def (x)
   x = x.to_s

> Rails' HashWithIndifferentAccess has unintuitive behavior, I don't
> want that unintuitive behavior copied to Ruby.  For example, what
> class are the keys?

I am not familiar with HashWithIndifferentAccess, what does it do
exactly and how is it unintuitive?

> >   2) If a Symbol doesn't respond to a method then coerce to String and
> > try that.
> >      (Perhaps certain methods would need to be excluded?)
>
> If there are already doubts about its usefulness it is probably a bad
> idea.  I don't want to have devote more brain-space to remembering
> what classes of objects I send to methods.

You misinterpret. Not doubt in usefulness, just working out certain
methods, like #class is an obvious excpetion, etc.

Whether there are any serious _technical_ issues with this idea, I'd
like to know. That's why I've inquired.

T.