Dave Burt 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
>
> Love your crazy ideas!

Thanks :)

> The main problem I see with this idea is that for "String < Symbol", a
> string must be expected to behave polymorphically like a symbol. Now, the
> only behaviour missing is immutability (I don't think the two methods
> id2name and to_int present an issue), but that's different enough -- if
> you're expecting an immutable symbol, what happens if it changes? (This is
> pertinent for hash keys, for example.)
>
> Now, Symbol < String actually makes sense to me, despite all the extra
> methods. Symbol could redefine most of the methods in
> (String.instance_methods - Symbol.instance_methods) to return a new mutable
> string. That would give your proposed automatic conversion. But this still
> leaves the problem of the behaviour of the mutator methods, <<, gsub!, et.
> al. -- these cannot work properly on a symbol; they'd have to be undefined
> or raise a NotImplementedError.
>
> And I think that works OK, and it's backwards-compatible except for:
>   if var.kind_of?(String) then var.chomp! end
> and possibly
>   begin
>     var.chomp!
>   rescue NoMethodError
>   end

I considered this, but it doesn't do well with the methods. It doesn't
make much sense to undefine all those methods, and not doing so would
make symbol much heavier, as would making it a subclass to begin with.
I think David makes a good point, it's more like Symbol <-> String. So
it can be thought of as going either way, but which way is more
advantageous?

Probably the first question to ask: does it even makes sense for a
subclass of an immutable to become mutable? Is that reasonable or even
possible?

But beyond that the coercion issue stands on it's own, String does not
need to be a subclass of Symbol or vis-versa for that to work. And
really this is the more significant concept here. Although if
subclassing facilitates that, even better.

Thanks,
T.