Path: utzoo!attcan!uunet!ginosko!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!network!ucsd!hub!eiffel!bertrand
From: bertrand@eiffel.UUCP (Bertrand Meyer)
Newsgroups: comp.lang.eiffel
Subject: Re: Eiffel questions
Summary: r
Keywords: assertions, types, is-a inheritance, export, genericity
Message-ID: <191@eiffel.UUCP>
Date: 24 Aug 89 06:42:38 GMT
References: <1567@laura.UUCP>
Organization: Interactive Software Engineering, Santa Barbara CA
Lines: 67

From article <1567@laura.UUCP> by guendel@exunido.uucp (Andreas Guendel):

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


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

> 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.

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.

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. Other approaches are possible and I appreciate the
arguments for some of them (see e.g. the article by Alan Snyder referenced
in the bibliography of OOSC) but I know of no one which is as simple,
consistent, and practical.


> The LAST POINT concerns the discussion on genericity versus inheritance
> [...] 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: Neither 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.

OOSC did not cover (except through a hint in exercise 19.5)
an important mechanism which has been present in all Eiffel
implementations distributed since July of 1988: constrained genericity.
This, I think, solves the problems raised here by Prof. Guendel.
Constrained genericity is the ability to specify a class as e.g.

	class SORTED_LIST [T -> COMPARABLE]

meaning that any actual generic parameter used for T must be a descendant
of COMPARABLE, with the operations <=, > etc., equipped with the proper
assertions.
  
> 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 Object-Oriented-language as example, so Eiffel is a good
> candidate.

I think if Prof. Guendel and his students use the Eiffel environment,
not just as a paper concept but as a practical framework for designing and
implementing good software, then they will have a much better feel
for what this technology really brings. An object-oriented design course
which would spend its time quibbling about language features would be rather
boring. What the students need to do is to build software, using
a good object-oriented environment together with the associated
methods, tools and libraries, and appreciate the results.

If Prof. Guendel's students do get this opportunity, 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.

-- Bertrand Meyer
bertrand@eiffel.com