🚀 go-pugleaf

I am posting the enclosed letter at the request of Bertrand Meyer.
We believe it raises issues of general interest.
================================================================================
To: meyer
Subject: a question
Reply-to: snyder@hplabs.hp.com
Date: Fri, 30 Dec 88 15:29:06 PST
From: Alan Snyder <snyder@hplsny>

Bertrand,

I have a question about the example you used in your column on multiple
inheritance in the Nov/Dec issue of JOOP.  To refresh your memory, you gave
an example of walking menus, which included a class SUBMENU that inherits
from both MENU and ENTRY.

It is clear to me why a SUBMENU must be an ENTRY: it must be an ENTRY
because it is an entry in a menu.  However, it is not clear to me why a
SUBMENU must also be a MENU.  As an alternative, I would consider having a
SUBMENU contain a MENU as an attribute; the execute action would have the
effect of bringing up that contained MENU.  I justify this alternative by
noting that the MENU operations are not needed on the object that lives in
the enclosing menu (the menu entry) and claiming that the two behaviors
need not be represented by a single object.

My question: What is your reasoning in favor of the multiple inheritance
solution over this alternative?  Do you see one alternative as strongly
superior to the other?  On what basis do you choose between these
alternatives?

Thank you.

  Alan