From: Charles Oliver Nutter Date: 2006-10-19T12:58:31+09:00 Subject: Re: Symbol < String in Ruby > 1.8 Rick DeNatale wrote: > On 10/18/06, Charles Oliver Nutter 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 headius@headius.com -- charles.o.nutter@sun.com Blogging at headius.blogspot.com