From: Daryl Richter <daryl@...>
Date: 2005-10-25T23:52:03+09:00
Subject: Re: String as Subclass of Symbol?

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!
> 
> 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.
> 

FWIW, Most Smalltalk class hierarchies have Symbol < String.

VisualWorks' class comment describes a Symbols as "... Strings that are 
represented uniquely."

> 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
> 
> Cheers,
> Dave 
> 
> 
> 

-- 
Daryl