Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wasatch!cs.utexas.edu!uunet!mcsun!unido!laura!exunido!guendel
From: guendel@exunido.uucp (Andreas Guendel)
Newsgroups: comp.lang.eiffel
Subject: Re: Eiffel questions
Summary: Misunderstood multiple-inheritance question, Eiffel genericity?
Keywords: assertions, types, is-a inheritance, export, genericity
Message-ID: <1573@laura.UUCP>
Date: 28 Aug 89 09:52:18 GMT
References: <1567@laura.UUCP> <191@eiffel.UUCP>
Sender: news@laura.UUCP
Reply-To: guendel@exunido.UUCP (Andreas Guendel)
Organization: University of Dortmund, W-Germany
Lines: 70

In my first posting I claimed:

> Another point is the multiple-inheritance problem. As in the book this
> feature is often used for implementation convienience: there is no way
> to argue that a fixed-stack "is-a"n array.

In his answer Bertrand Meyer replied:

> Sorry. It is *not* a matter of convenience. One can argue about this for
> years but to me an array-stack is an array, without any hesitation or
> qualification.

Concerning the years of discussion he is right. But as I have learned, an
array is a data-structure to which elements can be stored at a given index
and can be retrieved using the same index. The fixed-stack of the Eiffel-
book does not provide these functions.

Bertrand Meyer proceeds:

> The full discussion would require more subtlety but, in a nutshell,
> information hiding is NOT always desirable. (Yes, this is contrary to
> accepted wisdom, but too much of even apple pie can be dangerous to
> your health.) In the Eiffel view, information hiding does not
> apply to inheritance.

Bertrand Meyer misunderstood my point. I did not propose to hide the
implementation of superclasses against their descendants (though this is
an interesting question) but I argued against USING inheritance in the
stated situation.

If fixed-stack is implemented as a subclass of array, the type-checker will
assume that an instance of fixed-stack can be used wheresoever an array is
expected. But if you do that at any place, the algorithm given by Meyer to
make Eiffel type-save will raise an error since NO function on arrays can
be called on fixed-stacks. As I understood this algorithm it should be used
in situations where a class NEARLY CONFORMS to the specification of its
superclass but has SOME methods with restricted argument-types or which are
hidden to ensure the integrity of the subclass's instances state.

I was lucky to hear that current Eiffel includes constrained genericity.
There are two questions to this point, a theoratical and a practical one:

1. Do you (mainly Bertrand Meyer) share my opinion that inheritance can not
   adaequately model constrained genericity?

2. (For those as me who do not have any information on current Eiffel)
   Does Eiffel provide the mechanism of renaming some methods of parameter-
   classes for the use inside the generic class? This is necessary to handle
   existing classes which provide the needed functionality under different
   names without building subclasses to make them "real" comparables. Without
   this the problems of the prior solution keep existing.

At the end of his posting Bertrand Meyer concluded:

> If Prof. Guendel's students do get this opportunity [to use the Eiffel
> environment to build their own software], I have no doubt
> they will understand that our design decisions, including those which
> may appear shocking from a superficial analysis, are rooted in a careful
> examination of the goals, needs and challenges of practical software
> development.

Thanks for the "Prof." but at our university there are so many students that
non-Professors and even non-Doctors as me are encouraged to give lessons on
their area of research. I understand Meyer's last sentence as a first but not
exhaustive answer to my questions concerning parameter- and result-types as
special assertions and the default hiding of inherited features.

Thanks so far, also to those who responded by mail,

Andreas