Re: Symbol < String in Ruby > 1.8

Hi,

In message "Re: Symbol < String in Ruby > 1.8"
    on Thu, 19 Oct 2006 12:58:31 +0900, Charles Oliver Nutter <[e-mail]> writes:

|So then Symbol < String, except that it's frozen, and except that 
|there's only one instance per internal string. Big exceptions if you ask me.

Yes, Symbol is a Subclass of String that above two features added.

|What about immediately? Will symbols now show up in ObjectSpace? If not, 
|then there's another exception...we'll have a subclass of String whose 
|instances don't show up in ObjectSpace.

Symbols will show up in ObjectSpace list.

|And there's case statements...won't "when String" now match symbols too?

That may cause problem if you have distinguished symbols and strings
using case statements.

|> Ruby never required subclasses to be totally compatible with their
|> superclasses.  Inheritance is implementation factoring, not typing.
|
|But inheritance purely to reuse behavior? Hasn't that been roundly 
|proven a bad idea?

But when symbols behave like strings (except they are frozen), isn't
it natural to make them subclass of strings?  Symbol being subclass of
string is taken by Smalltalk people (without problem, I guess).

|If we're talking about Symbol responding to a number of methods String 
|also responds to, fair enough...put them in a module and mix them in, or 
|have both classes inherit from a common type. If we're talking about the 
|Symbol implementation inheriting some behavior for managing character 
|arrays, well you can do that behind the scenes without making an 
|explicit inheritance structure in Ruby-land. I'm just not sure what you 
|actually gain by doing something as heavyweight as having Symbol < String.

Possible.  First I want to see concrete (potential) problems from
symbol being subclass of strings, which works fine in Smalltalk for
long time.

							matz.