From: dblack@...
Date: 2003-02-11T11:40:14+09:00
Subject: inheriting from base classes

Hi --

Gavin Sinclair and I have been involved in an interesting exchange
about the merits (or lack thereof) of inheriting from base classes, in
particular String/Array/Hash.  This is also something that some of us
were chatting about at the conference in November.

We're both very interested in hearing what people's views are on this.
Do you ever subclass String, Array, and Hash?  Do you specifically
avoid doing so?

A brief summary of some of what we've been saying follows:

The argument in favor is that core classes already do a lot, and
specializing them can streamline things and economize on code.  For
example:

  class ClassRoster < Array

  class AssignmentValues < Hash

  class ExamQuestion::Title < String

as opposed to:

  class ClassRoster
    def initialize
      @actual_roster = []
    end
  end

and so on.

On the other hand, objects end up with more methods than will actually
be used.  There's a kind of possible looseness to the fit.

However... objects always at least potentially have "extra"
functionality in Ruby.  Is there any reason not to rely on the
documentation of an interface?  Don't we implicitly do that anyway
(since people can always add methods to objects and do unexpected
things, if that's what they're inclined to do)?

There's also some question as to whether classes that inherit from
base classes should themselves be fairly generic, like

  class OrderedHash < Hash

which also raises the question of where the boundary is between
generic and non-generic....

Thoughts?


David

-- 
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web:  http://pirate.shu.edu/~blackdav