Class explosion

[konstan@postgres.Berkeley.EDU (Joe Konstan)]

We are developing a rather large system using PCL and have come across a
software engineering problem when using multiple inheritance and orthogonal
mix-ins.

Basically, we have a collection of what we call "gadgets."  Each of these 
gadgets can (through multiple inheritance) become a widget, a field, or 
a widget-field (if both features are mixed in).  In addition, certain
gadgets can have other mixins as well.  So far, we have seen two possible 
solutions to this problem:

1.  Bite the bullet:  When the mixins are significant (multiple slots, 
methods defined on the new class) we just do multiple inheritance in the 
standard way and create the full set of classes.

2.  Slot-value discrimination:  When there is a set of mixins which are
all similar (and mutually exclusive) then the mixins can be handled by having
methods which disciminate on the value (or class) of a slot.  We do this with
macros which expand (method foo) to (real-method (bar foo) foo).  This works
well for certain things, but can't work well when the mixins are different or
compatible.

What would be nice would be automatic creation (and changing) of classes 
triggered by need.  For instance, if I could specify that binding a certain slot
of any gadget made it a field (or a widget) and the class would be assumed
(pcl::|gadget-widget-field| perhaps?) this would simplify the implementation.

What do other people do?  Is there some feature of PCL I'm overlooking?

Joe Konstan
Picasso Project
Computer Science Division
UC Berkeley