Classes vs Tagged Types - Terminology

[chl@clw.cs.man.ac.uk (Charles Lindsey)]

There has been much heated debate on comp.lang.ada concerning the
"tagged types" proposed for Ada 9x, and whether they shouldn't have
been "classes" for greater similarity with C++. I think the case has
been well made out that the tagged types in Ada 9x were the right
approach technically, given the need to maintain the look and feel of
Ada 83.

However, there is a need to decide on the correct terminology (few seem
to like the term "tagged") and, since a given term should hopefully
describe approximately the same concept in all languages where it
applies, I have widened the discussion to comp.lang.misc so that the
non-Ada world can have its say.

Here is what I have been teaching my students, by way of a taxonomy of
modularised programming. Note in particular the meaning I give to
various terms, so as to arrive at a (sort of) hierarchy of systems. I
offer this as an Aunt Sally to be shot at - I think it important that
some consensus should arise, and although Usenet discussions do not
usually lead to consensus we might at least find out what the options
are.


MODULE
A syntactic device for encapsulating groups of related declarations,
usually procedures, and usually with some means to limit the exported
identifiers so as to abstract away from implementation details.
MODULES come in two flavours:
	PACKAGES
	CLASSES

PACKAGE
A MODULE of which only one instance exists (a static module, if you like).
Things declared in the PACKAGE may be
	Operations (procedures or functions)
	Constants
	Variables
	Types
	possibly Other Packages
If the variables are not exported (but can only be initialized or
manipulated by exported operations), then we have an "ABSTRACT DATA
OBJECT". For example, I may write a PACKAGE "Stack" with hidden
implementation. This gives me just one stack.
Examples: Packages in Ada
          Modules in Modula-2
However, if I choose to declare and export one or more Types, but with
hidden internals so that only the exported operations can manipulate
them, then I have an "ABSTRACT DATA TYPE". For example, in a PACKAGE
"Stacks" I may export a Type "Stack", enabling clients to create as
many independent stacks as they wish. And I can encapsulate several
related types together and have operations that operate on, or know
about, all of them.

CLASS
A MODULE of which many instances may exist, as created by an explicit
"INVOCATION" (a dynamic module, if you like).
Things declared in the CLASS may be
	Operations (procedures or functions)
	Constants
	Variables
	Possibly other Classes
A CLASS is an elaborate kind of Type; INVOCATION typically occurs in a
variable declaration, or by an explicit creation operation (often
called 'new').
If the variables are not exported (but can only be initialized or
manipulated by exported operations), then we have an "ABSTRACT DATA
TYPE". For example, I may write a CLASS "Stack" with hidden
implementation, enabling clients to create as many independent stacks
as they wish.
Note that I cannot create a single ABSTRACT DATE OBJECT using CLASSes
(i.e. I cannot prevent a client from creating multiple instances). And
I cannot encapsulate several CLASSes together or declare operations
that operate on, or know about, several of them (except by declaring
"friends" as in C++ - not a very elegant solution IMHO).
CLASSes come in two flavours:
	Without INHERITANCE
	With INHERITANCE

CLASS Without INHERITANCE
Examples: Clusters in CLU
          Modules in Euclid

CLASS With INHERITANCE
Examples: Classes in Simula 67
          Classes in C++
          Classes in Smalltalk
          Classes in Eiffel
It is generally agreed that you need INHERITANCE to do any serious
"Object Oriented Programming". It is also common to refer to the
Operations as "Messages" in some systems.
CLASSes With INHERITANCE come in two flavours:
	SINGLE INHERITANCE
	MULTIPLE INHERITANCE
Eiffel is a good example of a language with MULTIPLE INHERITANCE.

To provide a counterpart to inheritance in PACKAGE-based systems, Types
also come in two flavours:
	TYPES Without INHERITANCE
	TYPES With INHERITANCE

TYPE Without INHERITANCE
These are the Types you have known and loved in just about every
programming language invented in the last 25 years.

TYPE With INHERITANCE
Example: Tagged Types in Ada 9x
These are to enable "Object Oriented Programming" in PACKAGE-based
languages. The concept seems good, and the (possible) advantages of
PACKAGE-based systems over CLASS-based systems are retained. The term
"Tagged Type" is used because values of such Types need to carry a Tag
around at runtime. However, some complain that implementation details
should not carry over into the syntax of High Level Languages, so maybe
some other term is needed. I offer "Classified Type" for your
consideration.

Conclusion
----------

I have offered the following concepts:

A. MODULE
    B. PACKAGE
        C. TYPE Without INHERITANCE
        D. TYPE With INHERITANCE
    E. CLASS
        F. CLASS Without INHERITANCE
        G. CLASS With INHERITANCE

I believe all these concepts are useful and necessary. Whether I have
matched the right term with each concept may be open to disagreement.
In particular, some will want to use the term CLASS for Concept G (but
what term for Concept E in that case?). There is also a need for a
better term than "Tagged Type" for Concept D.
-- 
Charles H. Lindsey -------------------------------------------------------------
           At Home, doing my own thing.           Internet: chl@clw.cs.man.ac.uk
Voice: +44 61 437 4506                            Janet:    chl@uk.ac.man.cs.clw
Snail: 5 Clerewood Ave., CHEADLE, SK8 3JU, U.K.   UUCP:     mucs!clerew!chl