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

Internet Message Format | 1993-01-02 | 6.3 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: 3 Jan 93 01:36:57 GMT
References: <[e-mail]> <[e-mail]>     <[e-mail]> <[e-mail]>     <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Lines: 120

[I won't speculate further on Booch's intentions for not elaborating
on the distinction between classes and types.  I don't think ridicule
or support for his actions based on speculation really gets us anywhere.
The important thing is to clarify our thoughts.]

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

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

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).

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

I agree with most of the arguments you give for distinguishing
between class and type, but the same arguments support not emphasising
the difference and instead using (and identifying) different levels of
abstraction.  Also, we seem to have a slightly different vocabularies
due to our no-doubt different backgrounds.

I will try to present your views in my vocab to make sure I really
understand them (correct me if I am wrong) and then discuss how my views
differ from yours.  Neither is fundamentally wrong.

You advocate that when analysing classes (or programs) I should keep
in mind two different domains.  One is at the level of representation;
the other is at some higher abstract level.  In effect I must second
guess what the programmer really had in mind when s/he designed the
class.  I should call my guess its type to distinguish it from its class
(representation).  I also need to keep in mind the consequences of
mapping from the abstract to the representation domains.

I advocate that when analysing classes you should be told up front
what level to think at and be given the appropriate level(s).  If you are
given just the implementation language version, you should think only
at that level (you might have a reasonable idea of what the high level
idea originally was, but you should not rely on any assumptions - our
misunderstandings are no doubt in part because we have both *assumed*
that we have exactly the same vocab).  The type of an object then
is the behaviour of (representation) values it can take on.  The class
is one way of defining these values.  Ideally, I would also be given
the high level specification (which would allow me to consider
alternative implementations) and the mapping between the two levels
(preferably also in a formal notation).  [I agree with you that this
is a long way from where the market is today]

pcg> For example it is vital to know that in C the 'mode' unsigned does not
pcg> correspond to the 'type' Naturals, and not even to the subset of
pcg> Naturals up to 2^N-1, but to the type 'Naturals mod 2^N'.

Using my proposed ideal methodology, I would need to look at the
operations available at both levels before I could determine whether
modulo effects needed to be taken in to account.  If there was no operation
which would dec/increment with wrap-around, then a mapping would not
necessarily have to deal with modulo effects.

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

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

I don't think you are nitpicking, just pointing out our slightly
different vocabs.

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

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

Ok, I wasn't being as clear as I could.  A type is a set of
behaviour values.  I agree that state values are insufficient.

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

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

You are not nitpicking.  You are just pointing out that we have different
definitions of class.  You say a class defines the representation of
a type.  I say it defines the type (at the current domain of thinking).

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

I agree.  I am all for formalism.  Natural language is vital but
can lead to confusion.  I was confused with your definitions and
you with mine.

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.

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

Yes, if I am not given the high level representation, I am missing
vital information which is one of the problems with many approaches.
My guessing the type/algebraic structure is just as dangerous, however.

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