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

Internet Message Format | 1993-01-02 | 5.8 KB

Path: sparky!uunet!pipex!bnr.co.uk!uknet!gdt!aber!fronta.aber.ac.uk!pcg
From: [e-mail] (Piercarlo Grandi)
Newsgroups: comp.object
Subject: Re: A Pre-Release FAQ
Message-ID: <[e-mail]>
Date: 2 Jan 93 21:14:15 GMT
References: <[e-mail]> <[e-mail]>
    <[e-mail]> <[e-mail]>
    <[e-mail]>
Sender: [e-mail] (USENET news service)
Reply-To: [e-mail] (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth
Lines: 110
In-Reply-To: [e-mail]'s message of 1 Jan 93 21: 56:57 GMT
Nntp-Posting-Host: decb.aber.ac.uk

On 1 Jan 93 21:56:57 GMT, [e-mail] (Paul King) said:

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

king> (Piercarlo Grandi) writes:

pcg> Here I disagree vehemently with Booch. [ ... ]  Indeed such terms
pcg> are so overloaded with different meanings and therefore so
pcg> ambiguous that they should always be qualified; ideally there
pcg> should be different word.

king> I did not find Booch's treatment of this subject that bad.

king> I do not believe there is a lot to be gained by placing too much
king> emphasis on the difference between type and class (and I have read
king> numerous articles on this topic - all of which still leave me
king> unconvinced).

Well, I can try again; distinguishing between a denotation and its
representation in a computer is vital in two respects:

    * to have a well founded understanding of what one is doing, a
      fairly rare commodity. It can be argued that programmers don't
      need to understand what they do, as long as it can be made to
      work most of the time. To this I cannot offer any objection
      (there is a large market for poor quality software developed
      with the trial-error approach beloved by "mere mortals", a
      very small one for robust software).

    * to know what kind of compromises one has done within
      the representation (i.e. if one does not know clearly what
      kind of type he was trying to represent one knows even
      less what kind of type has actually been represented).

For example it is vital to know that in C the 'mode' unsigned does not
correspond to the 'type' Naturals, and not even to the subset of
Naturals up to 2^N-1, but to the type 'Naturals mod 2^N'.  Or that
floating point numbers are (oh gosh, what I am saying) more similar to
rationals than to reals. This can either be clear in the mind of he
programmer, by knowing his types and classes, or it can be left as a
fairly amusing suprise for the customer. The latter wins market share,
the former does not.

king> I do however think it is useful to distinguish the
king> level of abstraction one is working at when you use the terms.

Nitpicking: It is not really the level of abstraction, it is the
*domain*; in each domain (denotations, representations) one can have
several levels of abstraction, which need not even be linked one-to-one.

king> I prefer to use simple definitions (and qualify when necessary): a
king> type is a set of values

Ahi, ahi, here you lose the 64k prize! A type is *not* a set of values,
despite what poorly edited articles like Cardelli&Wegner's report. The
operations one can do on a type are not limited to set operations. Also,
two very different types can be about same set of values (e.g. subset of
naturals from 0 to 2^N-1 and naturals modulo 2^n).

king> a class is one language construct that can be used to define a
king> type (and in some languages the only construct)

Ahi, ahi, I am in nitpicking mode here! A class defines the
*representation* of a type, not the type; types are usually defined in
appropriate notations. See, it's easy to slip even for you, and even if
you obviously know this well:

king> You can use classes from the implementation language to define the
king> implementation type, and use classes from your favourite OO
king> specification to define the abstract type.

If inaccurate expressions escape the attention of somebody who *knows*,
just imagine the confusion they can generate in those that don't; I
would say that you are very optimistic when writing:

king> If the level of abstraction is clear from the context then you can
king> just refer to types and classes without qualification.

It gets all too easy to mix things in a confusing way; even a lot of the
published literature is confused in exactly that way. I'd rather be
extra fussy than extra sloppy:

king> (I believe this is Booch's point - most often the level of
king> abstraction is clear from the context - though he didn't elaborate
king> specifically).

I got a rather different impression; that he wants to sell OO
consultancy, and the average customer does not want to be bothered with
talk about things like domains of discourse and other dangerous and
bolshevik innovation from pinko mathematically oriented guys. They want
to make things that work and sell, just like GM cars (;-> or MS Windows,
if you want a more successful example).

king> For objects, it doesn't usually matter whether you refer to their
king> type or their class.  And if the class mechanism is the only way
king> to define types, I would go so far as to say that the words type
king> and class are interchangeable.

This is an extremely dangerous attitude; for example it makes a lot less
obvious that a type/algebraic structure can be represented by many
different but in that sense equivalent classes.

Confusing type and class eventually results in disgraces like the
inability in most current OO languages to define in the same program
different implementations for the same interface. These are not small
consequences.
--
Piercarlo Grandi, Dept of CS, PC/UW@Aberystwyth <[e-mail]>
  E l'italiano cantava, cantava. E le sue disperate invocazioni giunsero
  alle orecchie del suo divino protettore, il dio della barzelletta