🚀 go-pugleaf

From: Jan Prins <prins@cs.unc.edu>
Date: Mon, 21 Nov 88 17:01:47 est
In-Reply-To: Jos Warmer's message of Mon, 21 Nov 88 09:18:11 PST <8811211718.AA26128@grand.COM>

Like Jos, I too have recently become acquainted with Eiffel, but I had not
thought of the subtle ADT implementation-visibility defect he described.

Although I agree with Jos that FIXED_STACK might, in this case, be better
thought of as a "client" of ARRAY rather than a "descendant", the general
problem of unauthorized access to ancestral features of a class remains.
Jos proposes a rule that would serve to prevent inheritance in cases
where the exposed parent-class features could be abused:

    "If a class B needs class A, then B should not be an heir of A if
     any operation on A corrupts the intended semantics of B.  In these
     cases B should be a client."

I would imagine that this rule would effectively prevent most inheritance
in ADT's.  Apart from deferred classes that impart some common structure on
descendants, most inheritance brings something into the class to be used
in the implementation of the class -- something subject to manipulation
via Jos' scheme.

My opinion is that this problem should be solved with declarations and the
type system.  Why make rules to recognize an apparent defect (don't inherit
here -- it's not safe!) rather than fixing it?

For example, one might require that a direct ancestor of a class must be
explicitly exported from a class, if it is desirable that others be able
to access the ancestor.  Or that the "inherit" clause be partitioned into
a "private" and "public" portion.  Thus class FIXED_STACK would make
ancestor STACK (a deferred class that defines a few functions common to all
representations of stacks) visible, but not ancestor class ARRAY.

With such a scheme and declarations

     a : ARRAY[INTEGER];         -- declare an entity of type ARRAY
     f : FIXED_STACK[INTEGER];   -- declare an entity of type FIXED_STACK

the type system refuses the assignment

     a := f;

since the class of "f" is not a publicly-acknowledged descendant of the
class of "a".  Consequently manipulation of "f"'s representation via Jos'
device is thwarted.

I suppose that inheritance-structure visibility declarations would be
transitive.  If  class C publically inherits B and B publically inherits A,
then, as far as the type system is concerned, features of class A are
polymorphic with respect to instances of classes A, B and C.

But before I go any further astray, it would be interesting to hear from
others whether Jos' observation is really perceived to be a problem.

Jan Prins
Dept. of Computer Science
UNC - Chapel Hill
prins@cs.unc.edu