🚀 go-pugleaf

I've been re-reading an exchange about preconditions and multiple inheritance
that took place in comp.lang.eiffel last year.  The example under
consideration was a class COMPANY_PLANE that inherited from PLANE and 
ASSET.  The precondition for "fly" in PLANE was that the user should
be a qualified pilot, the precondition for "use" in ASSET was that
the user should be a company employee, and the resulting precondition
for "fly" in COMPANY_PLANE was that the user should be both a qualified
pilot and a company employee.  The problem with this formulation is
that it strengthens the precondition of "fly" in the subclass instead
of weakening it.

The response to this was that a well-designed PLANE class would allow for
more specific qualifications, such as being allowed to fly the plane
by its owner.  Similarly, the ASSET class should allow for other
qualifications than being an employee, because not all employees can use
every asset.  So either:

	1. The class hierarchy should have been better designed in the
	   first place.
  or
	2. You should go back and redesign the class hierarchy.

It seems to me that case 2 is against the spirit of other decisions
made in the design of Eiffel.

I say this because the two most controversial parts of the Eiffel type
system, namely the covariant rule for types of the arguments of redefined
functions and the orthogonality of inheritance and visibility, were
expressly designed to handle cases when the inheritance hierarchy could not
be redesigned.  They are a recognition of the practical truth that we don't
always have an ideal base to work from.

By analogy, the "require" clause should make the same allowances.  There
may be times when we can't guarantee that the precondition of a redefined
function will be weaker than that of the original.  Eiffel shouldn't
enforce contravariance for assertions if it doesn't enforce it for
types.


I can think of two possible approaches:

	1. Make "require or" the normal way to specify preconditions
	   of redefined routines, as at present, but to keep "require"
	   as an option (or allow "require and" instead).
	
	2. Insist on covariant assertions, by replacing "require or"
	   with "require and".

Presumably the restrictions that currently apply to redefined routines with
argument types that are subtypes of the original would also apply to a
redefined routine that used "require and".

I admit that this seems an extreme point of view, but the covariance rule
seemed strong when I first met it.  Certainly the current situation, where
one sort of precondition (argument types) is covariant and the other
("require" clause) is contravariant, seems inconsistent.

Comments?

 Dave Berry, LFCS, Edinburgh Uni.      db%lfcs.ed.ac.uk@nsfnet-relay.ac.uk

"The thought of someone sharing one's own preferences without also sharing
 one's aversions strikes most people as utterly inconceivable." - C. A. Tripp.