Puzzling OO design problem

[Dirk Thierbach]

George Sakkis <gsakkis at rutgers.edu> wrote:
>>    A1 - A2 - A3 - A4 - ...
>>    |    |    |    |
>>    B1 - B2 - +  - B4 - ...
>>    |    |    |    |
>>    C1 - +  - C3 - +  - ...
>>    |    |    |    |
>>    D1 - D2 - +  - D4 - ...
>>    |    |    |    |

>> The solution is simply to include C3 in the list of parents of D4,
>> as in D4(C3,B4,D2). So for every hole in a column, you have to
>> include the first class (or classes, if the hole spans multiple
>> rows) to the left of the hole as parents if the class just below
>> the hole, in order from bottom to top. 

> Nice. I had taken for granted that you need to fill in the holes
> (D3,B3,C2), either manually or automa[tg]ically, but if you allow a
> class to inherit from more than two bases, you can pick a set of
> parents that does the job, without any boilerplate code or
> __metaclass__ magic. The downside of this approach is that it's even
> harder to see the big picture, as in the schematic notation above;
> remember that each column is a different version that resides in a
> separate module, so it's not obvious which classes should be the
> parents of each variation. 

It's obvious if you know which versions are available, and which
aren't. If you don't have this information, and you're only looking at
each module locally, than it's probably even safer (i.e., less likely
to confuse a casual reader of the source) to just generate all the
dummy classes manually. But that sort of makes your original problem 
irrelevant :-)

- Dirk