Path: utzoo!attcan!uunet!lll-winken!ames!ncar!husc6!bunny!dcr0
From: dcr0@bunny.UUCP (David Robbins)
Newsgroups: comp.lang.eiffel
Subject: Re: Conflict Between Class-as-Module and Class-as-Type (long)
Message-ID: <6424@bunny.UUCP>
Date: 11 Jan 89 14:57:35 GMT
References: <1884@vlot.cs.vu.nl>
Organization: GTE Laboratories, Waltham, MA
Lines: 60

In article <1884@vlot.cs.vu.nl>, jos@cs.vu.nl (Jos Warmer) writes:
> In article <6417@bunny.UUCP> dcr0@bunny.UUCP (David Robbins [me!]) writes:
>
>>This behavior violates my expectation of what I tend to call "specification
>>inheritance." 
>
> Inheritance in eiffel is always inheritance of the complete implementation.
> 
>>counterexample to this claim: class B is totally unequipped to handle
>>feature f1 (although the Eiffel implementation manages to secretly give B a
>>feature named f1, in violation of the semantics of Eiffel).
> 
> class B is a descendant of class A, so it IS equipped to handle feature f1.

That turns out not to be the case.  While it is true that B is a descendant of
A, I cannot interpret the Eiffel language definition to say that B is equipped
to handle feature f1 in my example.  Specifically, in my example, B has indeed
inherited f1 from A, but in B f1 was renamed and is known as f3.  Further, B
has not exported a feature named f1, and hence cannot claim to be able to
handle f1, even if a definition of f1 were to be available in B.  To be
equipped to handle f1, B must first of all export a feature named f1, and then
have an implementation of f1, either by inheriting one or by locally defining
one.

The semantics of renaming can be one of two things: (1) the original name
becomes undefined, making it possible to reuse the original name, or (2) the
original name remains defined, making it impossible to reuse the original name.
Eiffel's intention appears to be the former, as I can modify my example to
have B define its own f1 after renaming the inherited f1.

The ability of B to refuse to export a feature it inherited from A, which
feature WAS exported by A, is what confuses things here.  In all other
object-oriented languages with which I am familiar, a subclass exports
everything that its parent(s) export -- either by virtue of the lack of
explicit control over exports (e.g., Smalltalk-80) or by virtue of rules
that do not permit a subclass to refuse to export what its parent(s) export.
But in Eiffel, a subclass DOES NOT inherit the export list of its parent(s).
I found this out the hard way, when coding an Eiffel program thinking that
I wouldn't have to repeat in the subclass the export list of its parent.

This selective export capability is what really confuses the issue.  The fact
that a feature is defined in a class does not necessarily mean that the feature
can be used by a client: only if a feature is exported by the class can it be
so used.  This is true whether the feature is locally defined or inherited.
Thus, to reiterate my original point: even though class B is a descendant of
class A, it is not equipped to handle feature f1 unless B has explicitly
exported a feature named f1.  It is not sufficient for B to have inherited
a definition for f1 (although in my example B doesn't even have that!).

Study both of the examples I have posted to the net, and think very carefully
about the implications of inheritance combined with renaming combined with
selective export.  It took me several hours of thought to understand Eiffel's
problem with the combination of these three things.  Selective export really
confuses the meaning of inheritance in Eiffel!

-- 

Dave Robbins                    GTE Laboratories Incorporated
drobbins@gte.com                40 Sylvan Rd.
...!harvard!bunny!drobbins      Waltham, MA 02254