Path: utzoo!attcan!uunet!cs.utexas.edu!yale!mintaka!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!ox-prg!prg.ox.ac.uk!ajs
From: ajs@prg.ox.ac.uk (Adolfo Socorro)
Newsgroups: comp.lang.eiffel
Subject: Signature compatibility rules
Message-ID: <752@culhua.prg.ox.ac.uk>
Date: 23 Oct 90 09:09:58 GMT
Sender: news@prg.ox.ac.uk
Reply-To: ajs@prg.ox.ac.uk (Adolfo Socorro)
Organization: Oxford University Computing Laboratory, UK
Lines: 24

In article <668@caliban.mrcu> Tony Clark remarks that the rules in Eiffel
concerning the redefinition of signatures make the type system unsafe. I agree
with this. The rule he proposes is called ``contra-variance'' by some, and
implemented in a few languages, like Trellis/Owl (articles in various
OOPSLAs). Contra-variance, unfortunately, limits expressiveness.  Note,
however, that preconditions in Eiffel are required to observe this ``reverse''
behaviour. (Why, then, wasn't contra-variance adopted in Eiffel?)

I guess the choice of one rule of signature compatibility over the other
depends on whether you want absolute type security (required for the
implementation of so-called ``safety-critical systems''), or flexibility in
defining a class hierarchy.

A MUST article by Peter Wegner and Stanley Zdonik called ``Inheritance as an
Incremental Modification Mechanism'' (ECOOP 87), explores the different kinds
of redefinition possible with inheritance and their impact on the type-safety
of systems. They argue at one point that it is the ``subset relation rather
than the subtype relation that corresponds to the classical is-a relation'',
and that the fact that an A is always a B is in many contexts more important
than the fact that certain operations on As are inappropriate when performed
on Bs. Substitutability implies indistinguishability and is often
unreasonable.

Adolfo Socorro