Re: Symbol < String in Ruby > 1.8

Rick DeNatale wrote:
> On 10/18/06, Charles Oliver Nutter <[e-mail]> wrote:
> 
>> As Sam mentions in another post...what then is the difference between a
>> Symbol and a frozen String? Why have a separate type?
> 
> The main difference is that
> 
>   sym1 == sym2 implies sym1.object_id == sym2.object_id
> 
> This implication doesn't hold for strings, frozen or not.

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.

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.

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

> 
>> If there's a difference that's incompatible with String's behavior as a
>> supertype, I don't think Symbol < String is valid. If there's no
>> difference, I'm not sure I see the point in having Symbol.
> 
> 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?

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.

-- 
Charles Oliver Nutter, JRuby Core Developer
[e-mail] -- [e-mail]
Blogging at headius.blogspot.com