NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/object/3234

Text File | 1992-08-17 | 3.7 KB | 78 lines

Newsgroups: comp.object
Path: sparky!uunet!elroy.jpl.nasa.gov!decwrl!csus.edu!netcom.com!objsys
From: Bob Hathaway <[e-mail]>
Subject: Re: O.M() versus M(O) notation
Message-ID: <[e-mail]>
Date: Tue, 18 Aug 92 03:02:46 GMT
Organization: Object Systems
References: <[e-mail]> <[e-mail]>
Lines: 67

In article <[e-mail]>, [e-mail] (Ralph Johnson) writes:
>Piercarlo is right that there are many different definitions of the
>word 'type', and that sometimes the same person will use several of
>the definitions at once.  He also does a good job of enumerating the
>different kinds of definitions.  I'd like to focus on one particular
>distinction, between a mathematical object and a description of a
>mathematical object.

Not really.  Types and type systems are clearly defined in almost all
compiler texts (ASU), several modern languages (Emerald, Trellis/Owl),
several texts (Booch, Won Kim), and etc.  ***I could make up terms to my
liking too*** but it is better to use standard computer science terminology
if for no other reason than to be able to communicate well with colleagues.
Read up on the subject if you're confused!  The compiler terminology is
so clear there should be no confusion.

>...
>Thus, 'type' is usually taken to mean just the interface.  If a language
>also supported assertions, as Eiffel does, then type would be interface
>+ assertions.  (Note, however, that Eiffel defines type as interface +
>assertions + implementation.)

This is based on the made-up definition of interface.  Typically any kind of
interface includes everything defined within it.  Assertions/constraints
are obvously part of an interface if thats where they appear.

>In the OO community, claiming that classes and types should be
>different usually is part of an argument that interfaces and implementation
>should be seperated so that they can be reused seperately, and that
>inheritance should be different from "can this object be used in place
>of that object".  Bertrand Meyer is probably the chief opponent to this
>view.  He says that one of the chief advantages of OOP is that it
>*combines* interfaces with code, and that people who try to seperate
>them are making a mistake.  Thus, it would be a mistake to think that
>there is a concensus on this issue.

These issues are not mutually exclusive; they can be used as appropriate.
IMHO to claim types (verses class inheritance) should always be used
in trivial static deterministic domains or that class-based typing should
always be used in more flexible ones is unfounded.

>On 13 Aug 92 01:58:32 GMT, [e-mail] (Bob Hathaway) said:

>objsys> No, type and type systems are independent of implementation.  I
>objsys> think this distinction is very important from both a compiler
>objsys> and applications point of view.

>Bob is using 'type' as 'interface specification'.  I think he is fairly
>consistent with this use, though he also uses it to refer to the set of
>objects that meet the interface.

Not really, I believe I always refer to type separately from the "set of
objects that meet the interface".  It can get confusing at times since
most people are used to the combination of type and class.

>'Type' can mean
>  a mathematical object -- all 'objects' that meet a specification
>  an interface specification
>  an expression that denotes an interface specification
>  the data structure inside a compiler that represents an interface spec.

Type refers to an interface specification (or perhaps an expression returning
one) in the terms above ***within the domain of programming languages and
compilers***.

bob
[e-mail]