Xref: utzoo comp.object:3377 comp.lang.eiffel:1546
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!pyrltd!tetrauk!rick
From: rick@tetrauk.UUCP (Rick Jones)
Newsgroups: comp.object,comp.lang.eiffel
Subject: Re: Unification: Class=Type=Module
Message-ID: <1144@tetrauk.UUCP>
Date: 26 Apr 91 14:16:10 GMT
References: <1991Apr23.142800.12215@bony1.bony.com>
Reply-To: rick@tetrauk.UUCP (Rick Jones)
Organization: Tetra Ltd., Maidenhead, UK
Lines: 54

In article <1991Apr23.142800.12215@bony1.bony.com> richieb@bony1.UUCP (Richard Bielak) writes:
>
>One of the things I liked about "Object Oriented Software Construction"
>by B. Meyer, was the idea that a class is both a type and a module.
>This idea clears up the confusion as to whether inheritance extends or
>specializes.
>
>When a class is considered to be a type, inheritance specializes the
>type. The descendent type is type-compatible with fewer things, so it
>is more specialized.
>
>When a class is considered to be a module, inheritance adds more
>routines and attributes. Since the class can do more things it has
>been  extended.
>
>I also like the "cleanness" and simplicity of this idea. 
>
>I am curious whether other people think about this, and whether such
>"unification" has any disadvantages.

I believe it is a powerful notion, and is of course related to the concept of
abstract data types.  Personally I find that using the principle that a class
represents an ADT is the best guide to deciding what the classes should be, and
what should go into them.  I also add a little of the "responsibility" concept
as well.

In fact, in the module/type duality, the "type" is really the abstract type
rather than the language type.  I feel that the current debates about types and
type systems are taking an extremely narrow view of the subject.  In reality,
type conformance is not just about whether an object should "understand the
messages", or whatever the metaphor is in the parlance of any particular
programming language;  this is a language implementor's rather restricted view
of the world.  For type conformance to be meaningful in terms of the overall
design of a program, the semantic effects of each operation applicable to a
type need to be consistent as well.

This is where the module/type principle really starts to make sense, so that
extensions of the module become specialisations of the ADT.  Eiffel's
inheritance of assertions assures conforming semantics (given that the
assertions are used properly), so type conformance contributes towards overall
program correctness.

In real situations, things are not always so simple, and module
extension/specialisation can make certain features of the inherited ADT
invalid, so the descendant is not fully type compatible (even seen as an ADT)
with its parent - e.g. the infamous polygon/rectangle case.  It is, however,
conformant in respect of the features which it does support.  This is one of
the issues which the extended type checking proposed for Eiffel will address.

-- 
Rick Jones, Tetra Ltd.  Maidenhead, Berks, UK
rick@tetrauk.uucp

Any fool can provide a solution - the problem is to understand the problem