Xref: utzoo comp.lang.eiffel:1357 comp.object:2481
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!sdd.hp.com!elroy.jpl.nasa.gov!ames!ncar!csn!boulder!gore!jacob
From: jacob@gore.com (Jacob Gore)
Newsgroups: comp.lang.eiffel,comp.object
Subject: Re: Inheritance and Information Hiding
Message-ID: <120021@gore.com>
Date: 1 Feb 91 16:30:48 GMT
References: <1991Jan23.224203.3206@runx.oz.au>
Reply-To: jacob@gore.com (Jacob Gore)
Organization: Gore Enterprises
Lines: 32

/ comp.lang.eiffel / bertrand@eiffel.UUCP (Bertrand Meyer) / Jan 30, 1991 /
> 	Will anyone take up the simplest example (discussed in my
> posting <485@eiffel.UUCP>): a class POLYGON exists and has
> a procedure ``add_vertex'', which it exports.
> You want to add a class RECTANGLE. What do you do?

As long as we combine the subtyping (specification) hierarchy with
implementation reuse hierarchy (I'm not saying it's a bad thing, although
I'm beginning to seriously wonder), the option most obvious to me is:

5. RECTANGLE needs to replace the 'add_vertex' it inherits with one that
does nothing.

I don't see why RECTANGLE needs to welch on the contract of its superclass
in the simplest case, and I don't think it should.

However, if POLYGON's 'add_vertex' contains in its contract the
postcondition "num_vertices = num_vertices + 1", there is no way RECTANGLE
can uphold the contract.

So, I see Bertrand's reasoning behind his option 4, but I am wondering if
there is a fundamentally different approach to the whole thing...

I'd also like to refer people on a rather good letter on this subject, one
that demonstrates what its author sees as a fundamental problem (though
without offering a concrete solution):

	Paul W. Abrahams.  "Subject: Objectivism" (in ACM Forum).
	Communications of the ACM, Vol. 34, No. 1, Jan. 1991, pp. 15-16.

Jacob
--
Jacob Gore		Jacob@Gore.Com			boulder