On Tue, Feb 11, 2003 at 11:26:50PM +0900, dblack / candle.superlink.net wrote:
> But then there's the question: if a ClassRoster is essentially an
> ordered list of Student objects, and that list is going to be added
> to, sorted, subtracted from, mapped over, etc. etc....  what is the
> disadvantage to having it subclass Array (rather than sort of shadow
> Array via instance variables and rewriting of methods that Array
> already has)?  I'm willing to believe there are disadvantages, but I'm
> not succeeding in picturing an actual scenario where it would play out
> badly.

The biggest disadvantage I see is that you are exposing many more
methods than you'd like.  One side effect of this is the following: an
Array in Ruby can hold any kind of object, but a ClassRoster holds only
Students.  So any method that can add elements to the Array might want
to make sure it is adding only Students.  Providing checks like this is
ugly and unproductive, particularly since it would change the behavior
of the base class.

It's easier, IMO, to provide a minimal interface (each() and [] and []=)
and then mixin the Enumerable module.

Paul