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
Subject: Re: Do we really need types in OOPL's?
Message-ID: <736@tetrauk.UUCP>
Date: 24 Sep 90 10:41:21 GMT
References: <0yw10qr@Unify.Com> <411@eiffel.UUCP>
Reply-To: rick@tetrauk.UUCP (Rick Jones)
Organization: Tetra Ltd., Maidenhead, UK
Lines: 60

In article <411@eiffel.UUCP> kimr@eiffel.UUCP (Kim Rochat) writes:
>In article <0yw10qr@Unify.Com>, dbrus.Unify.Com.brian@unify.uucp (Brian Meyerpeter ) writes:
>> I have a question that has been bugging me for a long time.  
>> 
>> Why does Eiffel try to be a typed language? 
>> 
>> In an ideally object-oriented language shouldn't you be able to assign
>> a class of any type to another class of any type as long as the 
>> client that is assigning them knows their interface and does not 
>> abuse it?
>
>The last comment is the reason Eiffel is typed.  Because of typing, the
>compiler can verify that class interfaces (i.e., types) are properly used, 
>and a type error cannot occur at run time.  In contrast, dynamically 
>typed languages get type errors at run time instead of compile time.

A fundamental confusion here is the distinction (or lack of it) between types
and classes.  Classification is really all about taxonomy, and being able to
describe something by saying "this is like X except ...".  This is a very good
method for defining a software module (i.e. a class), and the basis of code
re-use in OOPLs.

A type on the other hand is a definition of an interface.  It says what an
object is prepared to do for a client.  For dynamic binding to work reliably,
it is important that an object is never asked to do something it doesn't
support, therefore the issue of type conformance is important.  If this
conformance can be checked and guaranteed early, the predictable reliability of
the system is improved.

A class and a type don't have to be the same thing, but given the state of the
art in compilers it is a useful pragmatic to treat them as the same.  I.e. the
inheritance tree is used as the basis for determining type conformance.  For a
compiler to analyse type conformance purely based on interface definitions
independent of inheritance is clearly a non-trivial issue.  I'm not an expert
on compilers so I shall not attempt to comment further.

A view of the future evolution of Eiffel's type system is described in two
papers by Bertrand Meyer, re-posted in comp.lang.eiffel last July.  They
anticipate support for a notion of partial conformance, still based on class
inheritance but both less restrictive and more reliable (that's the way I read
it - perhaps someone would correct me if I've got it wrong?).


Along similar lines, I am working on a client/server architecture using OO
principles (which is the obvious way to treat it), and the problems of
encapsulation and conformance are being dealt with by having the client
interrogate the server to get a definition of its interface.  The client then
knows what it can or cannot do, and can make dynamic decisions as to how to
use the server;  it avoids the run-time problem of trying to "send a message"
and getting it bounced.

In my case the domain is clearly defined and the interface definition is
tightly structured, but is this approach applicable in a more general form in
an OOPL?

-- 
Rick Jones			The definition of atomic:
Tetra Ltd.				from the Greek meaning "indivisible"
Maidenhead, Berks, UK		So what is:
rick@tetrauk.uucp			an atomic explosion?