🚀 go-pugleaf

According to hoelzle@neon.Stanford.EDU (Urs Hoelzle):
>Here's the scenario on which my claim is based:
>
>1) You haven't written A and B yourself but bought them from someone.
>   That is, you cannot change A or B to inherit from a common base
>   class.
>
>   The solution to this is to subclass A and B (with classes SubA and
>   SubB) in order to define the necessary "interface glue".

There is a better solution: Create an abstract GenericFoo class, which
is the element type for the FooCollection.  Then define subclasses of
GenericFoo called FooA, FooB, etc.  Here's the key part: each FooA
_refers_ to an A, each FooB _refers_ to a B, etc.

With this scheme, all member functions interesting to the collection
(and the collection's clients) can be implemented as virtual functions
defined in GenericFoo and implemented in all subclasses of GenericFoo.

This alternative solves the problem of subclassing A and B, because
FooA can refer as easily to a SubA as to an A.
-- 
Chip Salzenberg at Teltronics/TCT     <chip@tct.com>, <uunet!pdn!tct!chip>
   "All this is conjecture of course, since I *only* post in the nude.
    Nothing comes between me and my t.b.  Nothing."   -- Bill Coderre