Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!julius.cs.uiuc.edu!apple!agate!shelby!neon!craig
From: craig@Neon.Stanford.EDU (Craig D. Chambers)
Newsgroups: comp.object
Subject: Re: OO Ada -- another way
Message-ID: <1990Nov7.220902.13393@Neon.Stanford.EDU>
Date: 7 Nov 90 22:09:02 GMT
References: <PCG> <77500062@m.cs.uiuc.edu> <443@eiffel.UUCP>
Organization: Stanford University
Lines: 64

In article <443@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes:
>	This is of course a natural consequence of the view that a class
>is two things: modular facility and type. This view is applied
>to its full extent in Eiffel, where there is no other modular facility
>than the class, and every possible type is based on a class. The
>rules applying to inheritance (e.g. information hiding rules, the
>covariant conventions for typing etc.) follow directly.

I disagree that Eiffel's typing rules "follow directly" from treating
a class as both a module (a collection of method implementations) and
a type (a set of procedure/function interfaces).  I think that the
goal of a language's static type system should be to be able to
guarantee statically that type-checked programs will never manipulate
objects in ways that weren't intended (e.g. no "message not
understood" or "access denied" errors), for as many reasonable
programs as possible.  Eiffel must not have this as its goal, because
there exist well-known holes in its static type checking (e.g.
covariant typing rules).

Unifying modules and types into classes doesn't require these holes in
type checking.  Consider Trellis/Owl as a language with the same
unification that preserves static type checking.  However, unifying
modules and types as classes (and unifying "submoduling" (code
inheritance) and subtyping as subclassing) *does* lead to some
sacrifices.  Trellis/Owl sacrifices submoduling of classes that aren't
legal supertypes (subtyping is considered more important than
submoduling).  Eiffel sacrifices static type checking, and so treats
submoduling as more important than (correct) subtyping.  Bertrand
Meyer's recent proposals to extend Eiffel's type checking to plug the
holes in the static type system effectively allow a subclass to be a
submodule without being a subtype, thus separating the two concepts
that supposedly are one thing.  C++ has a limited way of doing this
already with its private base classes.

Perhaps the "right" approach is to use a single language construct to
define a collection of interfaces and optionally a collection of
implementations (called, say, a class), and have two ways of
inheriting from classes, one as both a subtype and submodule and one
as a submodule only.  This leads to a similar conciseness of
expression that is an advantage of the unified approaches of most
popular OO languages (the programmer doesn't have to write separate
type constructs and module constructs for common abstractions), but
preserves the important distinction between subtyping and code
inheritance.

>	(c) reverse assignment attempt 

What does this mean?

>	I do not know, of course, what Professor Johnson really has
>in mind, but if anyone has a good ``impossible case'' for typing
>I would be glad to see it discussed on the net.
>(Yes, this is a challenge.)

What about the examples I posted a few weeks ago as part of this
ongoing discussion?  They were perform:, become:, and the
implementation of OrderedCollection in Smalltalk (see pp. 231-233 of
the "Blue Book").  The OrderedCollection problem could be avoided if
the language includes a default instance of each class (such as a null
pointer), but null pointers (void references in Eiffel) just introduce
a whole new class of run-time errors that cannot be detected
statically (e.g. sending messages to null pointers).

-- Craig Chambers