🚀 go-pugleaf

In article <1101@hub.ucsb.edu> bertrand@hub.ucsb.edu (Bertrand Meyer) writes:
...
>	I wish I had perfect answers. My general guideline is
>clear: I see inheritance as the ``is'' relation and client as
>``has''. These are natural language terms and not perfectly
>rigorous. I am aware in particular that our form of inheritance
>(where a descendant can hide a feature exported by an ancestor
>or conversely) may appear to cast some doubts as to what ``is''
>really means. However the following points are worth
>considering.
...
>2. The more difficult case is when ``is'' apparently applies
>but you are not quite sure (as in the submenu case). However it
>seems to me
>that in a sense you can always interpret ``is''
>as ``has'' and thus do away with inheritance altogether.
>(Again I am aware of the limitations of using
>such natural-language-based criteria, but we are in the domain
>of information modeling here and I don't see how to avoid human
>interpretation.)
>If ``every A may also be viewed as a B'' (the basis for applying
>``is'', or inheritance), then you can always reinterpret this
>by saying ``every A has a part of it which is a B''. In other
>words, A could be rewritten as a client of B. It seems to me
>that if you take your favorite example of unquestionable
>inheritance (say polygons and rectangles, or anything else) you
>can rewrite it in such a way that it uses the client relation
>instead (i.e. each rectangle will have an attribute that refers
>to an object describing its polygon features).
...

One of the major differences between inheriting a class and being a client of a
class is that being a client restricts you to using the public interface.  If
you inherit you have access to all the features, public and private, of your
ancestor.  There is nothing wrong with this in the cases where you really need
it.  However, if the choice is between inheriting and being a client then the
current inheritance mechanism is overkill since you only required access to the
public features.  This violates the principle of information hiding discussed
in chapter 2 of The Book.  At our company we are working on a large system with
an expectation of over 1000 classes.  Any time we inherit instead of become a
client we are increasing the dependencies in the inheritance trees, which are
becoming very complex.

It is my opinion that it would be useful to be able to distinguish between
unrestricted inheritance (the current implementation) and limited inheritance
which would allow only the public interface to be "inherited".  Since your
other arguments for using inheritance versus becoming a client of a class made
sense to me I feel that what I think is a relatively minor language extension
would remove a major objection to the use of inheritance.

I am fairly new to both Eiffel and OOP and this suggestion is only my opinion.
I'd be interested in hearing what you and others think of it.  I have been
working on largish software products for a long time and know from bitter
experience how hard things get when your dependencies get too large.  I believe
this extension to the langauge would allow a useful technique to be retained
while keeping the dependency problem down to one of primarily the public
interface, which may be hard enough to manage itself.

I'd just like to add that I appreciate your participation in this newsgroup.
Its like being in at the start of C and being able to talk to Kernighan and
Ritchie.  I hope Eiffel is just as successful.
-- 
Don Walker               Cognos Incorporated     S-mail: P.O. Box 9707
Voice: (613) 738-1338 ext 5934                           3755 Riverside Drive 
  FAX: (613) 738-0002                                    Ottawa, Ontario 
 uucp: uunet!mitel!sce!cognos!donw                       CANADA  K1G 3Z4