From: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.object
Subject: Re: A Pre-Release FAQ
Date: 1 Jan 93 18:53:11 GMT
	<37B01UW@minnie.zdv.uni-mainz.de>
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth


On 31 Dec 92 10:49:41 GMT, beckmann@Informatik.Mathematik.Uni-Mainz.DE
(Markus Beckmann) said:

beckmann> In article <PCG.92Dec29203617@decb.aber.ac.uk>, pcg@aber.ac.uk
beckmann> (Piercarlo Grandi) writes:

pcg> A point of order too: a FAQ should not be about the FAQ author's
pcg> opinions; the FAQ should only be a list of facts...

pcg> Are you so incredibly sure that the type of an object and its class
pcg> are the one and same concept, such that 'type' and 'class' are just
pcg> synonyms?

beckmann> A list of facts:

The fact is that several authors make that mistake, and some don't
(IMNHO).  I'd like to comment with my well founded (;->) arguments about
it, because it's a subject that is important in its own right, not
because of the FAQ, and it gets rehashed eveyr now and then, and I have
a missionary streak.

[Warning: I have trimmed down the quotations to those parts I thought
more significative for the points I make]

beckmann> Booch ('OOD with applications', p.59) "The concept of a type
beckmann> derives primarily from the theories of abstract data types.

OK so far. The firm grounding of the notion of type is in algebraic
theory.

beckmann> ... For our purposes, we will use the terms type and class
beckmann> interchangeably.(/footnote A type and a class are not exactly
beckmann> the same thing; [ ... ] For most mortals, however, separating
beckmann> the concepts of type and class is utterly confusing and adds
beckmann> very little value. It is sufficient to say that a class
beckmann> implements a 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 (I have the
suspicion that he "feels" the difference, he just has been exposed to
too many Booch like verbiage to express itt naturally).

beckmann> ... and an other one for the mortals...

Maybe instead of patronizing the reader Booch could have tried to make
the little extra effort and avoid confusing an abstract entity and its
implementation, a fairly gross and grave thing. It is a bit like
confusing a numeral and a number, or a picture of something and the
something. "Ceci n'est pa un pipe", as Magritte, a *painter* remarked.
Are computer scientists to be presumed unable to make the same
distinction?

beckmann> B. Meyer ('OO Software Construction',p.61) "Level 4 (Classes):
beckmann> Every non-simple type is a module, and every high-level module
beckmann> is a type. ...  A language construct combining the module and
beckmann> type aspects is called a class."

So Type != Class.

beckmann> dto. (p.72) "There are no other objects than class instances:
beckmann> any object is an instance of some class C. C is said to be the
beckmann> _type_ of the object."

Here he seems to reverse himself. Either C is a module plus a type, or
it is just the type. Another case of careless editing. (Cardelli and
Wegner in their article I referred to speak of type, incompatibly, as
either a language construct or as a set of values).

beckmann> B. Stroustrup ('What is "Object-Oriented Programming"',
beckmann> article) "The declaration of class (that is, user defined
beckmann> type)..."

Ah but here Stroustrup is referring to the language construct in both
cases! Indeed a problem we had in the past with the FAQ author is that
he did not seem quite capable of distinguishing between 'declaring a
type' (a language entity) and the type of a value (an algebraic entity).
Lots of people have difficulty with that too.

beckmann> S. Khoshafian ('Object Orientation', p.49) "A class
beckmann> incorporates the definition of the structure as well as the
beckmann> operations of the abstract data type. Thus, a class defines an
beckmann> abstract data type."

Another glaring example of poor wording. The class does not *define* an
abstract data type; it does *implement* one.

|>              This would be amazing news to most of the people who
|>              have
|>   been working on formal methods and OO systems.

beckmann> Are the above books exotic?

No, and as I read them they support my two contentions: that type is
not the same as class, and that however several people make the
distinction, and several don't. It also supports a new contention I can
make: that several authors patronize their readers assuming that they
are too dumb to understand the distinction, as "too abstract", beyond
"mere mortals". I really dislike this; the distinction is not something
that can be swept under the carpet. Even if programmers were "mere
mortals" they ought to be told.

beckmann> I think a FAQ should not discuss 'all' the aspects of
beckmann> different definitions but give an overview of what all the
beckmann> posting is about.

But if the most obvious aspect of an item is controversy, it should
document the controversy. Your quotations (thanks for taking the time)
are an excellent example of this; even if they were meant to demonstrate
that several authors write 'type is more or less the same as class",
they actaully reveal a far wider spectrum of opinion, as in:

	type is not the same as class, but mere mortals cannot
	understand the difference.

	a type declaration can also be called a class declaration,
	at least in some *languages*.

	classes *implement* types, plus some other aspects.

and so on. If I start quoting from papers that emphasize that type is
not the same as class, then we have even more diversity. To be informed
at least summarily of the diversity is an important value added of a
FAQ.

beckmann> Otherwise every article should have a preface like "I use
beckmann> objects of Grandi-type (or class? ;-), I am talking about
beckmann> Hathaway-Classes...".

Indeed such terms are so overloaded with different meanings and
therefore so ambiguous that they should always be qualified; ideally
there should be different words. I have been pondering this for a while;
I would call type as an algebraic entity 'type', as this is an
established custom in maths, and type as a language construction a
'mode'. 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.
--
Piercarlo Grandi, Dept of CS, PC/UW@Aberystwyth <pcg@aber.ac.uk>
  E l'italiano cantava, cantava. E le sue disperate invocazioni giunsero
  alle orecchie del suo divino protettore, il dio della barzelletta
Newsgroups: comp.object