In favor of tagged types (was Classes versus tagged types was Ichibah flames, and flames out over, Ada 9X)

[barbey@lglsun.epfl.ch (Stephane Barbey)]

In article <1993Mar16.173520.23858@evb.com>, pole@evb.com (Tom Pole) writes:
: In article <1993Mar12.225943.3648@nosc.mil> sampson@nosc.mil (Charles H. Sampson) writes:
: >In article <1993Mar12.160136.6106@evb.com> pole@evb.com (Tom Pole) writes:
: >
: >>
: >>A class is a class. If Ada wants to add the ability to have 
: >>inheritance/specialization similar to what is available in other
: >>OOPL's, the OO world calls the common definition
: >>of a type which supports specialization a class, and instantiations
: >>of that type objects. Ada can use the same terms if it wishes.
: >

Class is not obligatory linked with inheritance. For example, seek
"class-based" in your little OO dictionary.


: >     What about that part of the published OO world that uses the terms
: >object and instance for those concepts?  The point of that rhetorical
: >question is, of course, OO terminology is far from fixed.  If the 9X
: >boys can come up with a better term, particularly if they're trying to
: >make it clear that the thing they've defined is not the same as the C++
: >thing, good for them.
: 
[...]
:
: OO is not fixed among all practicioners, Agreed.
: 
: Far from fixed, nope.
: 
: The terms that still cause people to get to bed late and drink too much
: beer at OOPSLA are not class, object or instance. 
: 
: -- 
: 
: Thomas Pole


  The OO terminology is not fixed. For instance, OOPLs use different terms
to designate:

- the class from which another class is derived (Smalltalk: superclass,
  C++: base class),

- the structure of a class (CLOS: slot, Eiffel: attribute, Smalltalk:
  instance variables, C++: member data elements, Ada 9X: components),

- the subprograms that describe the behavior of an object (Eiffel:
  routine, Smalltalk: method, C++: member function, Ada 9X: primitive
  operations).

- ... 

  People use different terms for the same idea. (That's why we speak of
the tower of Babel of programming languages, don't we ? :-). Sometimes,
people use the same term for different ideas. (Did you read the
discussion on polymorphism in comp.objects?).


Conclusion 1: There is no need for Ada 9X to adopt a given
  OO terminology, because, to quote S. Tucker Taft, it is still 
  "a huge muddle now".

 
: An object is a logical collection of state and functionality.
: (if you want to argue unfixed, let's argue the oft used but
: never defined 'logical collection' )
: 
: A class defines the commonality of a set of objects.

  There are objects in Ada, and their definition is in accordance with
your definition. However, what you call a class is commonly known as a
type.  (A class is not only a type, but also provides encapsulation,
thus the equation class=module=type in Eiffel and other "pure" OOPLs).

  In languages like C, there was no support for encapsulation, and a
weak support for user-defined types (structs). In comparison, Ada 83
offers packages, strong typing and type derivation. Therefore, there is
no need for a entirely new construct, say a "C++ like" class construct.
We just can re-use some of Ada 83's mechanisms.


Conclusion 2: you can have the equivalent of a C++ class in Ada 9X,
  using some of the concepts of Ada 83 and some of the concepts
  introduced in Ada 9X.


As a consequence of reusability of concepts, it will be easier for the
users of Ada 83 to transition to Ada 9X and OO technology.

: 
: >
: >     That said, I have a lot of trouble with tagged.  It's just a long-
: >held belief of mine that a language feature shouldn't even appear to be
: >suggesting its implementation.
: 
: Here Here !!!
: (or is that hear hear ? See the problems you have 
: when your semantics aren't fixed ? )
: 
: 	Thomas
: 
: >
: >				Charlie
: 

  In both Ada 83 and Ada 9X, a class is a set of types with similar
values and operations. There are language-defined classes, for example
the class of integer types, and user-defined classes. As far as I know,
there are no C++ terms to designate an Ada 9X class (maybe "hierarchy
of classes rooted at type T", although it is not satisfying). Moreover,
there are no way to control that an object belongs to a given class!

  Since all objects in a class of types share properties (states and
behavior), it is convenient for the programmer to manage them in a
uniform way (thus the introduction of dynamic binding and class-wide
programming in Ada 9X). As we also want to be able to distinguish the
types of those objects, we need an information that tells what the type
of an object is at run-time, i.e. a tag. That's why Ada 9X calls the
types that can be put in a user-defined class tagged types. That's not
(only) suggesting their implementation : it affects their semantics as
well.

  There are no tags in C++, and it causes lots of trouble with
heterogeneous data structures. Usually, you have to program the tag
yourself and do the dispatching (dynamic binding) by hand.


Conclusion 3: all in all, the adopted terms speak for themselves. As
  long as you care to study it, the Ada 9X terminology is clear,
  precise and makes clear what the introduced features are.


Therefore I support the "tagged type" and "class" terminology used in
Ada 9X.


-Stephane Barbey

--
Stephane Barbey				"It's not easy getting real wings"	
INJ-335, barbey@di.epfl.ch