[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
padl-2.1 published
- To: <acad!alce!greg>
- Subject: padl-2.1 published
- From: Mark S. Miller <mark>
- Date: Wed, 23 Aug 89 15:59:55 PDT
- Cc: <us>
- In-reply-to: <Greg>,55 PDT <8908210050.AA00466@xxxxxxxxx>
Date: Sun, 20 Aug 89 17:50:55 PDT
From: acad!alce!greg (Greg Lutz)
> > > > I have installed a subclass of Object in Object.hxx called
EQObject. Subclasses of EQObject inherit EQ behavior for these
messages.
You mean you ran around to all definitions of classes which were
missing these required functions and added EQObject to their (usually
singleton) list of base classes?
Another C++ feature that we have so far succeeded in completely
avoiding is multiple inheritance. What I did is change some classes
from specifying Object as their base class to specifying EQObject as
their base class. EQObject in turn specifies Object as its base
class. We still just have a single inheritance tree. Note that our
tools (formic, stubble, xlint, the CLASS macros) only work with single
inheritance, so we're sort of locked in for now.
Although it may have some nice abstract justification, multiple
inheritance is usually more trouble than it's worth. Where the
traditional object oriented community likes to use inheritance to
combine functionality (with different base classes representing
different components), we like to have a network of objects pointing
at each other & sending messages around. This way we have all the
object-oriented abstraction & polymorphism benefits in this
composition.
The hard problem which resulted in the invention of multiple
inheritance is the design of the Symbolics Window System. The
exercise that persuaded me that message sending among small objects is
sufficient to replace complex inheritance is the Viewers work at PARC
by Peter Deutsch & Dean. Not only did they succeed in doing with
object composition what the symbolics folk did with multiple
inheritance (class composition?), the resulting system was much more
powerful, modular, orthogonal, and understandable.
This is not to say that there aren't valid reasons for multiple
inheritance, and Bjarne did BY FAR the best job of defining a multiple
inheritance system of any language designer I know of. I rather
suspect that there is a disciplined style of using Bjarne's multiple
inheritance which will actually be good programming practice. I think
we should avoid it, though, until we can afford the intellectual
effort to figure out how to use it well.