NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/object/4688

Internet Message Format | 1993-01-01 | 3.6 KB

Path: sparky!uunet!munnari.oz.au!bunyip.cc.uq.oz.au!uqcspe!cs.uq.oz.au!king
From: [e-mail] (Paul King)
Newsgroups: comp.object
Subject: Re: A Pre-Release FAQ
Message-ID: <[e-mail]>
Date: 1 Jan 93 21:56:57 GMT
References: <[e-mail]> <[e-mail]>     <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Lines: 68

In <[e-mail]> [e-mail] (Piercarlo Grandi) writes:

[Booch quote about difference between class and type ...]

>Here I disagree vehemently with Booch. The result of his attitude ("I
>know that the difference is important, but you cannot grasp it") is that
>people like Hathaway get utterly confused terminology ...
> ... Indeed such terms are so overloaded with different meanings and
>therefore so ambiguous that they should always be qualified; ideally
>there should be different word.

I did not find Booch's treatment of this subject that bad.
I do not believe there is a lot to be gained by placing too much
emphasis on the difference between type and class (and I have read
numerous articles on this topic - all of which still leave me
unconvinced).  I do however think it is useful to distinguish the
level of abstraction one is working at when you use the terms.
I prefer to use simple definitions (and qualify when necessary):
    a type is a set of values
    a class is one language construct that can be used to define
        a type (and in some languages the only construct)

If you need to make the distinction between an implementation type
and an abstract type, then qualify as in this sentence.
You can use classes from the implementation language to define
the implementation type, and use classes from your favourite OO
specification to define the abstract type.  I prefer to qualify in this
way rather than invent new words as it allows me to use many levels
of abstraction, rather than just implementation and specification
(referred to as the abstract level above).  So, I might have
types at the informal user-requirements level, the high-level
design level, the low-level design level and the implementation level.
I may use classes to define these types at the last three of these
and possibly the first if I have some informal requirements notation.

If the level of abstraction is clear from the context then you
can just refer to types and classes without qualification.
(I believe this is Booch's point - most often the level of abstraction
is clear from the context - though he didn't elaborate specifically).
For objects, it doesn't usually matter whether you refer to their type
or their class.  And if the class mechanism is the only way to define
types, I would go so far as to say that the words type and class
are interchangeable.

>So for example
>
>    struct complex { float re,im; complex(...) .... ; };
>    complex i(0,1);
>
>would declare a mode complex and 'i' would be a variable initially
>denoting a value that represents the imaginary unity of the Complex type.

I would use type or class to refer to `complex' whichever seemed
appropriate.  If you really need to distinguish between the complex
type that is representable using two non-infinite floats
and the mathematical counterpart using infinite reals then refer
to the latter as an abstract type (or preferably specify what you
mean in a specification language and then refer to its
specification or high-level design type).

Just my opinions,

Paul.
--
Paul King                                   _-_|\
Dept. of Computer Science, Univ. of Queensland                  /     X
Queensland, Australia, 4072                          \.--._/
[e-mail] (ACSNET)                               v