From: Paul Nulty <paul.nulty@...>
Date: 2007-12-13T21:40:05+09:00
Subject: Re: composition/inheritance/subclassing standard lib classes


> Now, can you say with a straight face that "Every Deck of Cards is an
> Array"? Maybe not.
>
> So, on to reason number two, the practical reason: Arrays in Ruby are
> an unwieldy beast. Traditionally, Collections have been very hard to
> model in classical object-oriented programming languages. Is it
> Array < OrderedCollectionWithDuplicateEntries < CollectionWithDuplicateEntries
> or Array < OrderedCollectionWithDuplicateEntries < OrderedCollection?
> There are many ways to solve this, Multiple Inheritance or Traits for
> example, but Ruby has found a rather elegant solution: just squish the
> entire Smalltalk Collection Hierarchy in one single Class! And so, a
> Ruby Array is not only an Array but also a List (first), a Queue
> (shift/unshift), a Stack (push/pop), a Vector, a Bag, a Set (uniq, |,
> &), a Tuple and even a Matrix (transpose)!
>
> This power comes with a cost, though: 71 public instance methods on
> Array (not counting the methods inherited from Object or mixed in from
> Enumerable)! Do you really want to have all of that on your Deck of
> Cards? What does "transpose" mean in the context of a SongList?
>
> Ruby makes it *very* easy to delegate to an Array instead of
> inheriting from it, through the use of metaprogramming, Delegator,
> Forwardable and friends. It also makes it easy to keep the Array "look
> and feel" on your own objects, because a lot of what looks like Array
> specific operators are actually just methods (e.g. [], []=, <<) that
> you can just as well implement on your own class. And thirdly, several
> useful methods aren't actually methods of the Array Class but of the
> Enumerable Module that you can mix in into your own class.
>
> So, by delegating a couple of methods to an Array and mixing in
> Enumerable you get something that looks an awful lot like an Array but
> is actually a Domain Object custom-tailored to your specific needs.
>
> An alternate approach if you don't want a specialized Domain Object
> but rather a specialized generic Collection is described here:
> <http://Rubylution.Ping.De/articles/2005/12/21/rubys-rich-array-api/>.
> The basic idea is: copy the Array Class (remember, Classes are just
> Objects, too!), remove the methods that you don't want, et voilą,
> there is a List or a Stack or a Queue which isn't a subclass of Array
> but actually "inherits" its behaviour.
>
> jwm

Hi,

Thanks for such a detailed reply. There are some concepts there that
are new to me (delegator/forwardable). I love the way that the Array
class has so many useful built in methods, but i can see why you don't
want an interface that big for every class.

> <http://Rubylution.Ping.De/articles/2005/12/21/rubys-rich-array-api/>.

In this link that you posted, i don't understand the Array.extract
syntax? where is this "extract" method coming from?

thanks again,

bob