Xref: utzoo comp.lang.eiffel:534 comp.object:637
Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!ukc!edcastle!lfcs!db
From: db@lfcs.ed.ac.uk (Dave Berry)
Newsgroups: comp.lang.eiffel,comp.object
Subject: Re: Eiffel, assertions, Object-Z and library books.
Keywords: eiffel, assertions, object-z
Message-ID: <1469@castle.ed.ac.uk>
Date: 21 Dec 89 14:14:22 GMT
References: <1818@laura.UUCP>
Reply-To: db@lfcs.ed.ac.uk (Dave Berry)
Organization: Laboratory for the Foundations of Computer Science, Edinburgh U
Lines: 27

In article <1818@laura.UUCP> guendel@exunido.UUCP (Andreas Guendel) writes:
>In article 526 of comp.object Paul Johnson asks:
>> 2) Are Multiple Inheritance and Software Contracting incompatable?
>
>> Suppose we have the classes PLANE and ASSET.  From these we derive
>> COMPANY_PLANE.  A precondition for FLY in PLANE is to be a qualified pilot.
>> A precondition for USE in ASSET is to be a company employee.  Hence to
>> fly a company airplane, you must be a company employed qualified
>> pilot.  This strengthens the pre-conditions on both base classes.
>
>If the precondition is strengthend
>there is no subclass-relation semantically as the software contracting
>rule shows. But this is not unique to multiple-inheritance, it may even
>occur in single inheritance hierachies.

I can see how Andreas' position applies to single-inheritance hierarchies.
I can't see how it answers the multiple-inheritance example given by Paul
Johnson.  Surely a company plane *is* both an asset and a plane?  This applies
both conceptually and practically; in practice one might want to add the
company_plane to a list of company assets and to a list of planes.

If one accepts Andreas' position, how should this example be implemented?

Dave Berry, Laboratory for Foundations      db%lfcs.ed.ac.uk@nsfnet-relay.ac.uk
    of Computer Science, Edinburgh Uni.	    <Atlantic Ocean>!mcvax!ukc!lfcs!db

"leIsANewEntertainment:GuerillaWarStruggleIsANewEntertainment:GuerillaWarStrug"