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: <6423@bunny.UUCP>
Date: 11 Jan 89 14:55:36 GMT
References: <1884@vlot.cs.vu.nl>
Organization: GTE Laboratories, Waltham, MA
Lines: 67

From article <1884@vlot.cs.vu.nl>, by jos@cs.vu.nl (Jos Warmer):
> In article <6417@bunny.UUCP> dcr0@bunny.UUCP (David Robbins [me!]) writes:
>>
>> ...
>>
>>export f1.  Since B does not export f1, I would certainly not expect
>>"b_invoked_as_a.f1" to succeed.  After all, it is trying to call feature f1
>>of an instance of B, which does not export any such feature.  In fact, B
>>does not even possess a feature named f1!
>>
> 
> This behaviour is correctly defined in eiffel. It is even neccesary to define
> this behaviour if you want compile-time checking.
> The entity "b_invoked_as_a" has static type A.  It is impossible for the
> compiler to know the dynamic type of "b_invoked_as_a". So if the compiler has
> to check whether some feature is applicable to "b_invoked_as_a", it can only
> look at the features of A. If a feature is not redefined, then the definition
> from A is used. This choice can only be made at runtime.
> 
> The rules are:
>     The features that may be applied to an entity depend on the static type
>     of the entity.  The actual definition used may depend on the dynamic type.
> 

It is precisely these static checking rules with which Eiffel's support of
renaming combined with selective export conflict!  In the absence of renaming
and selective export, it is guaranteed that any subclass of A will possess
an exported definition of all features exported by A; a feature may be
inherited from A or redefined by B.

Selective export throws a big monkey wrench into this scheme of things.  With
selective export, it becomes possible for B to refuse to export a feature
that A exports.  When B does so, that feature is no longer visible to a
client of B, and Eiffel's static checking of references through static type
B reflects this fact.  But this gives rise to a problem that Eiffel does
not solve: when B is allowed to refuse to export a feature that A exports, it
is not possible to statically check whether a use of that feature is valid.
Since it remains valid to assign an object of class B to a variable with
static type A, the reference to "b_invoked_as_a.f1" cannot be statically
checked!

Renaming also throws a monkey wrench into things.  With renaming, it becomes
possible for B to inherit feature f1 from A, but for f1 to be known within B
as f3.  B is then free to locally define a feature named f1.  But B is also
free to leave the name f1 undefined!  This would not be a problem were it
not for selective export, for without selective export B would at least be
required to have some definition of f1 if A exported an f1.  But in any case,
Eiffel's implementation seems to have a problem with renaming: I posted another
example in which A.f1 was renamed as B.f3 and B.f1 was locally defined; here,
if B is called through A's interface, A's f1 is used, even though B does have
its own definition of f1.  This seems very inconsistent.

Anyway, I will reiterate what I think is the crucial point of my original
posting and another followup I posted:

   Selective export really changes the meaning of inheritance in Eiffel!

It is the export list that defines what features of a class are visible to
clients of the class, and the export list neither gets inherited nor is
subject to any rules about what can and cannot be exported.

Study my two examples and think carefully about the consequences of the
combination of inheritance, renaming, and selective export.-- 

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