Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!gem.mps.ohio-state.edu!ginosko!uunet!mcsun!mcvax!unido!laura!exunido!guendel
From: guendel@exunido.uucp (Andreas Guendel)
Newsgroups: comp.lang.eiffel
Subject: Eiffel questions
Summary: Problems in teaching Eiffel
Keywords: assertions, types, is-a inheritance, export, genericity
Message-ID: <1567@laura.UUCP>
Date: 23 Aug 89 11:15:07 GMT
Sender: news@laura.UUCP
Reply-To: guendel@exunido.UUCP (Andreas Guendel)
Organization: University of Dortmund, W-Germany
Lines: 63

Dear Eiffel Community,

since I plan to teach Object-Oriented Design I have read (among others)
the book "Object-oriented Software Construction". From my history I am
a Smalltalk-80 programmer but for padagogical reasons I would prefer to
take a typed OO-language as example, so Eiffel is a good candidate.

Obviously in any language there are a lot of design decision which
become a matter of criticism, for example the Type-Security discussion
on Eiffel. My first question belongs to this area:

As I understand typing, it is a form of statically checkable assertions.
The argument-types of a routine belong to its preconditions, the result-
type to its postconditions. Therefor it seems reasonable to have the
same rules for typing and for assertions in case of inheritance:
Weakening the preconditons of a redefined routine in a subclass corres-
ponds to allow a supertype of the arguments, making the postcondition
stronger corresponds to return a subtype of the old return-type. This
treatment of assertions (the dynamic ones) in proposed in the book to
guaranty an is-a relation between the subclass and its superclass. But
as argued by Bertrand Meyer in one of his postings to this group (and as
many examples show), for the type-assertions weakening the preconditions
does not conform to practise. This makes it very difficult to talk about
real "is-a" inheritance, doesn't it? How shall I explain this problem in
my course?

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. So I would prefer to use the
implementation-variant, in spite of its little overhead. I only accept
multiple inheritance if an object really belongs to more than one
concept (see below), at least in a course on principles of OO Software
Construction. But this is not really a problem since I can leave out
those examples.

More difficult to understand is the default hiding of inherited features.
Since "is-a" inheritane is the basic principle of the design-method and
assumed by default by the type-checker, it would probably be a better
default to export all the features exported by the superclass. Anything
that may obscure "is-a" inheritance (renaming, redefinition, hiding)
would have to be explicitly stated (keyword: hide). Does anyone know the
reason behind this decision?

The LAST POINT concerns the discussion on genericity versus inheritance
and constrained genericity in Eiffel (this is of course an important
theme in a planed course). The solution proposed in the book (e.g. to
get a comparable version of some class) does not really provide the
benefits of constrained genericity: Neigther can existing elements of
the base-class be used as comparables, nor can elements of the comparable
version be used as elements of the base-class.
In oposite to the fixed-stack example above, here multiple inheritance
would be justified: an xyz_comparable "is-a" xyz and "is-a" comparable!
In a language with constrained genericity this unconvinience doesn't
appear: the elements of a sorted list are normal elements of their base-
type with some operations renamed for use inside the sorted-list stuff.

It would be very important for my course if someone would answer my
questions or correct my opinions where they need to be corrected. Reply
eigther by email or directly to this group.

Thanks in advance and sorry for the length of this posting,

Andreas