From: Rick DeNatale <rick.denatale@...>
Date: 2007-05-13T00:30:59+09:00
Subject: Re: Why was the "Symbol is a String"-idea dropped?

On 5/12/07, Brian Candler <B.Candler@pobox.com> wrote:
> On Sat, May 12, 2007 at 04:20:10PM +0900, enduro wrote:
> > I was exited when I heard that
> > Symbol was made a subclass of String
> > in Ruby 1.9, September last year.
> >
> > But then I heard that the experiment
> > was stopped after only two months.

>
> The two objects have very different behaviours, so why should one be a
> subclass of the other?
>
> * Symbols are immutable, Strings are mutable
> * Symbols are singletons, Strings are not
>
> I think this is an example of the traditional OO dilemma: "is Circle a
> subclass of Oval, or is Oval a subclass of Circle?" One argument says: a
> Circle is a subclass of Oval because you can use an Oval to draw a Circle -
> you just need to constrain its parameters. Another argument says: an Oval is
> a subclass of Circle because it extends the behaviour of Circle.

More a dilemma with languages which force implementation inheritance
to track a notion of type inheritance.

Such languages assume that somehow type hierarchies are natural and
objective.  In reality they aren't.

Years ago I was discussing this with Brad Cox, and he came up with
another example.  In a strongly typed OO language you might have a
hierarchy like this:

   class Object
      class Vehicle < Object
         class Automobile < Vehicle
            class Car < Automobile
            class Truck < Automobile
                class Ambulance < Truck

So an ambulance is a specialized truck.

But then in a new context you might want to model a ski resort and now
an ambulance can be either a toboggan, or a helicopter.

These are the kind of things which tie strongly typed frameworks in
knots of implementation tangled with type.


> Ruby says: we don't care. Make a Circle class, and make an Oval class. Make
> them both respond to whatever methods make sense (e.g. all shapes may be
> expected to have a 'draw' method). If you want to share implementation code
> between them, then use a mixin.

Or in other words, languages like Ruby provide fairly rich mechanisms
for sharing implementation, and don't tangle this up with policy
decisions about how objects should be classified, which in the real
world can become messy, or at least context/requirements dependent.

If anyone wants to ponder the difficulties of making an objective
type/classification hierarchy in more depth, I'd recommend reading the
essay "What , if Anything, is a Zebra" by Stephen Jay Gould, or for a
more in-depth and challenging read, "Women, Fire, and Dangerous
Things" by George Lakoff
-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/