Re: Classes vs Tagged Types - Terminology

Re: Classes vs Tagged Types - Terminology

[pipex!uknet!warwick!zaphod.crihan.fr!univ-lyon1.fr!scsing.switch.ch!sicsu]

In article <1993Apr6.164642.9487@cenatls.cena.dgac.fr>, bruniau@cenatls.cena.dg
ac.fr (Christophe Bruniau) writes:
: 
: In article <1993Apr5.155419.8598@evb.com>, jgg@evb.com (John Goodsen) writes:
: |> In <1993Mar25.155650.16244@inmet.camb.inmet.com> 
: |> stt@spock.camb.inmet.com (Tucker Taft) writes:
: |> 
: |> >
: |> >In Ada 9X, it is only class-wide types (named "T'Class") that provide
: |> >subclass matching.
: |> >                      ^^^^^^^^^^^^^^^^^
: |>                        Didn't you mean "tagged types" :-)
: |> 
: |> Can we take this as an indicator that you are about ready to
: |> abondon the "tagged type" terminology and adopt the more
: |> appropriate "class type" terminology?  It seems that even
: |> members of the 9X project are shying away from using "tagged
: |> type" these days, so why don't just finish the scenario and
: |> adopt the "class type" syntax and terminology ...
: |> 
: |> fingers crossed...
: |> 
: 
: Does anyone know the original reason why "tagged type" was introduced,
:  instead of something like "class type" ?
: 
: Christophe BRUNIAU     bruniau@cenatls.cena.dgac.fr

Yes. I posted the reasons I had found about two? weeks ago. It basically
comes down to an implementation issue.

It is possible to come up with a language that does not use tagged
and is not ambiguous. The problem with this approach is that it would
be far too difficult to implement.

Since tagged is there for implementation reasons (representation clauses
and declaring tagged types below the library level are the stumbling 
blocks) I don't think you could come up with a better term than tagged.

However it is for this very reason that you will get nowhere it you try
and push tagged type as being a feature. The OO features being added are
class-wide types (T'Class where T is a tagged type) and type extension
(between tagged types) as well as hierachical library units.

Robb

Re: Classes vs Tagged Types - Terminology

[mcsun!julienas!newsserver!geant!bruniau]

In article <1993Apr5.155419.8598@evb.com>, jgg@evb.com (John Goodsen) writes:
|> In <1993Mar25.155650.16244@inmet.camb.inmet.com> 
|> stt@spock.camb.inmet.com (Tucker Taft) writes:
|> 
|> >
|> >In Ada 9X, it is only class-wide types (named "T'Class") that provide
|> >subclass matching.
|> >                      ^^^^^^^^^^^^^^^^^
|>                        Didn't you mean "tagged types" :-)
|> 
|> Can we take this as an indicator that you are about ready to
|> abondon the "tagged type" terminology and adopt the more
|> appropriate "class type" terminology?  It seems that even
|> members of the 9X project are shying away from using "tagged
|> type" these days, so why don't just finish the scenario and
|> adopt the "class type" syntax and terminology ...
|> 
|> fingers crossed...
|> 

Does anyone know the original reason why "tagged type" was introduced,
 instead of something like "class type" ?

I think that a terminology like "class type" would make explanations like
 the one below more straightforward.
This could make Ada-9X more "sexy", for those who don't see immediately
its advantages :-)

>Given a tagged type T and two derived types T1 and T2, you get the
>following:  T1'class and T2'class are subclasses of T'class.
>Any object belonging to the specific type T1 is thus an instance of
>T1'class and of T'class.  Same for T2, mutatis mutandis.  Any object
>belonging to the specific type T is an instance of T'class (but not of
>T1'class, of course). Thus:
>	X : T;  -- instance of T'class
>	Y : T1; -- instance of T1'class and T'class
>	Z : T2; -- instance of T2'class and T'class


Christophe BRUNIAU     bruniau@cenatls.cena.dgac.fr

Re: Classes vs Tagged Types - Terminology

[Harry Koehnemann]

In article <1993Apr5.155419.8598@evb.com> jgg@evb.com (John Goodsen) writes:
>In <1993Mar25.155650.16244@inmet.camb.inmet.com> 
>stt@spock.camb.inmet.com (Tucker Taft) writes:
>
>>In Ada 9X, it is only class-wide types (named "T'Class") that provide
>>subclass matching.
>>                      ^^^^^^^^^^^^^^^^^
>                       Didn't you mean "tagged types" :-)
>
>Can we take this as an indicator that you are about ready to
>abondon the "tagged type" terminology and adopt the more
>appropriate "class type" terminology?  It seems that even
>members of the 9X project are shying away from using "tagged
>type" these days, so why don't just finish the scenario and
>adopt the "class type" syntax and terminology ...

The term "class-wide" appears to apply to the usage of a type
classification (when declaring a parameter type for a subprogram
specification), while your favorite term "tagged type" is used
during the definition of the classification . i.e. "tagged" isn't
going away.

IMO, it would be a large mistake to refer to Ada's tagged types
as classes.  I understand your desire to use terms common in the
OO world, but great confusion lies ahead for those OO people that
have programmed using a class construct.  Classes and type extensions
are by no means the same construct and it is appropriate to make
their names distinct - "tagged"/"extended"/???, but not "class".
--
Harry Koehnemann			Arizona State University
koehnema@enuxha.eas.asu.edu		Computer Science Department

Re: Classes vs Tagged Types - Terminology

[John Goodsen]

In <1993Mar25.155650.16244@inmet.camb.inmet.com> 
stt@spock.camb.inmet.com (Tucker Taft) writes:

>
>In Ada 9X, it is only class-wide types (named "T'Class") that provide
>subclass matching.
>                      ^^^^^^^^^^^^^^^^^
                       Didn't you mean "tagged types" :-)

Can we take this as an indicator that you are about ready to
abondon the "tagged type" terminology and adopt the more
appropriate "class type" terminology?  It seems that even
members of the 9X project are shying away from using "tagged
type" these days, so why don't just finish the scenario and
adopt the "class type" syntax and terminology ...

fingers crossed...


-- 
John Goodsen                EVB Software Engineering, Inc.
jgg@evb.com                    - Ada & Object Oriented Training/Products
(301) 695-6960                 - Ada GUI & Graphics Tools and Training
                               - Software Reuse, Process & Environments

Re: Classes vs Tagged Types - Terminology

[Mark A Biggar]

In article <1993Apr5.155419.8598@evb.com> jgg@evb.com (John Goodsen) writes:
>In <1993Mar25.155650.16244@inmet.camb.inmet.com> 
>stt@spock.camb.inmet.com (Tucker Taft) writes:
>
>>
>>In Ada 9X, it is only class-wide types (named "T'Class") that provide
>>subclass matching.
>>                      ^^^^^^^^^^^^^^^^^
>                       Didn't you mean "tagged types" :-)

No he meant Class-wide.  The class-wide type T'class is a type whose
value set includes the union of the value sets of tagged type T and
all tagged types derived from T (even including those that havn't
been defined yet).  If I have a procedure with the header:

procedure FOO(X: T);

the only a member of tagged type T can the used as an actual without 
using a type conversion.  If the header was:

procedure FOO(X: T'CLASS);

then any member of tagged type T or any tagged type derived from
T can be used as an actual and inside FOO the parameter X retains
its tag, unlike the first case, where if you passed a parameter of
a type derived from T (using a type conversion) X stiil has the
tag of tagged type T.

One other case should be mentioned, If I call the first FOO above
with an actual of type T'CLASS, then the system does dynamic dispatch
to the body corresponding to the actual tag of the value contained in
class-wide actual.

--
Mark Biggar
mab@wdl1.wdl.loral.com

Classes vs Tagged Types - Terminology

[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

Re: Classes vs Tagged Types - Terminology

[Richard A. O'Keefe]

In article <C4AGp4.1Fw@clw.cs.man.ac.uk>, chl@clw.cs.man.ac.uk (Charles Lindsey) writes:
...
> CLASSes come in two flavours:
> 	Without INHERITANCE
> 	With INHERITANCE
...
> It is generally agreed that you need INHERITANCE to do any serious
> "Object Oriented Programming".

Where have you _been_, mate?  There are quite a few OO languages
based on delegation rather than inheritance.  There are good arguments
each way, and the issue is far from settled.  The "Actor" model is
based on delegation. SELF is based on delegation, and is available
free.  Several concurrent object-oriented languages are based on
delegation.  (Delegation is where an object that elects not to handle
a method call directly hands it off to another object, not to itself
viewed as belonging to another type.)

Re: Classes vs Tagged Types - Terminology

[Tucker Taft]

In article <17255@goanna.cs.rmit.oz.au> 
  ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:

>In article <C4AGp4.1Fw@clw.cs.man.ac.uk>, 
>  chl@clw.cs.man.ac.uk (Charles Lindsey) writes:
>...
>> CLASSes come in two flavours:
>> 	Without INHERITANCE
>> 	With INHERITANCE
>...
>> It is generally agreed that you need INHERITANCE to do any serious
>> "Object Oriented Programming".
>
>Where have you _been_, mate?  There are quite a few OO languages
>based on delegation rather than inheritance.  . . .

It seems that the more fundamental distinction is with or without
(run-time) polymorphism.  If you look at a C++ class that
has no virtual member functions (and hence no polymorphism),
it is little more than an abstract data type that uses
prefix notation for referring to its operations.
You can inherit from it, but that is not particularly ``interesting''
without virtual member functions.
Ada 83 also has this limited kind of inheritance, where you
can derive from a type to create a new type.

More important than inheritance (even with type extension), 
in my view, is the ability to have multiple implementations of 
a given abstraction.  This is what separates an "object-oriented"
language (like Ada 9X or C++) from an "abstraction-oriented"
language (like Ada 83 or CLU).  In an "abstraction-oriented"
language, each abstraction interface has exactly one implementation,
and hence all calls on operations of the interface can be
statically bound.  

In an "object-oriented" language, a given
abstraction interace may have many implementations (typically
organized into some kind of inheritance hierarchy, though that
is not essential), and each object carries around some identification
of which particular implementation it originates from.

In other words, to be a true object-oriented language, objects
have to be "self-identifying" (or "type-identifying") in some way, 
so that even though various objects may all be treated as supporting
a single abstract interface, the appropriate implementation can
be executed when a given operation of the interface is invoked.

It is misleading to associate polymorphism with the term "class,"
since in both C++ and Simula-67, it is the virtual functions
that provide (run-time) polymorphism.  Without virtual functions,
a class is just a capsule for an abstract data type.  One thing that is
rightly associated with the term "class" is the property of
"subclass matching."  That is, if a formal parameter is of
a given class, then an entity belonging to any subclass of
that class is acceptable as the actual parameter.  

In Ada 9X, it is only class-wide types (named "T'Class") that provide
subclass matching.  Specific types (like "T") do not provide
subclass matching.  And of course, it is "private" that signals that
a type is an abstract data type in Ada (83 or 9X).  
We considered using "virtual" on subprograms as the signal for 
polymorphism, but it is relatively easy to prove that types
with some virtual and some non-virtual primitive subprograms have 
some undesirable properties that make thorough testing very difficult.  
For example, imagine a type T that has three operations, A, B, and C,
where A and B are virtual, but C is not.  We could test how A, B, and
C work together on T, and each derivative of T (T2, T3, T4, etc.),
but still not know whether they work together properly when
we use dynamic binding, since with dynamic binding, we would execute
the "C" of the nominal (static) type of the parameter, and 
the "A" and "B" of the actual (dynamic) type of the parameter, 
a combination that had never been tested.  

In other words, if you have N types in a hierarchy,
with some operations virtual and some not, there are N*N/2 cases
(approximately) to test, representing the various combinations
of nominal (static) type and actual (dynamic) type of a given parameter.
However, so long as the operations are either all virtual, or all
non-virtual, this quadratic explosion of test cases doesn't occur.

Given the above phenomenon, we concluded that it was better
to mark the type by saying that all of its (primitive) operations
are "virtual" (aka dynamically bound, aka "dispatching"), rather
than to mark each operation individually.  Since the objects
of a type hierarchy with dynamically bound operations must be 
self-identifying, we chose the term "tagged" in analogy with
"tagged architecture" to indicate that all operations of the
type are dynamically bound.  We also considered "polymorphic"
(too many meanings), "extensible" (the objects aren't extensible,
the set of types is), "dynamic", etc.  None of them seems as
suggestive and unambiguous as "tagged," which also has
a nice connection to the fact that we are moving the concept
of "tagged architectures" into software.

It is intereseting to note that the ANSI C++ committee is currently 
considering providing some kind of run-time-checked type casting.  
However, as currently proposed, this will only be provided for classes 
with at least one virtual member function.  Hence, they recognize
that they have two kinds of C++ classes, those whose objects
don't identify themselves, and those whose objects do.  Much
as in Ada 9X, we will have two kinds of abstract data types
(private types), those whose objects don't identify themselves
(untagged), and those whose objects do (tagged).

An example of a C++ class that would probably have no
virtual member functions, and hence be effectively untagged 
would be "complex," since there is little advantage in having 
virtual member functions for such an abstract data type.  
Similarly, in Ada 9X, a private type "complex"
would have no particular reason to be tagged.

In any case, the Ada term for "C++ class" is essentially 
"package-with-a-private-type."  Both of these terms correspond
to the more general concept of an "abstraction" as developed
by Guttag and Liskov in the late 70's. 
The term "tagged" in Ada 9X takes the place of having to write 
(in C++) "virtual" on each member function (primitive
operation) of the abstract data type, and indicates
that the corresponding objects are "self-identifying."

NOTA BENE:  The above is admittedly a technical discussion,
not a marketing one.  If you want to talk marketing, please
start a different thread of discussion.  (Charles Lindsey's note
was trying to focus on the underlying technical issues, not 
the marketing ones, and this response has tried to keep that focus.)

S. Tucker Taft   stt@inmet.com
Ada 9X Mapping/Revision Team
Intermetrics, Inc.
Cambridge, MA  02138

Re: Classes vs Tagged Types - Terminology

[Stephen J Bevan]

In article <1993Mar25.155650.16244@inmet.camb.inmet.com> stt@spock.camb.inmet.com (Tucker Taft) writes:
   [ much that I agree with except for the following ]
   More important than inheritance (even with type extension), 
   in my view, is the ability to have multiple implementations of 
   a given abstraction.  This is what separates an "object-oriented"
   language (like Ada 9X or C++) from an "abstraction-oriented"
   language (like Ada 83 or CLU).  In an "abstraction-oriented"
   language, each abstraction interface has exactly one implementation,
   and hence all calls on operations of the interface can be
   statically bound.  

One of my favourite languages, ML, allows multiple implementations of
a single interface via parameterisation and to some extent so does
Ada83 via generics.  Can this be reconciled with the above statement?

bevan

Re: Classes vs Tagged Types - Terminology

[Tucker Taft]

In article <BEVAN.93Mar26110200@panda.cs.man.ac.uk> 
  bevan@cs.man.ac.uk (Stephen J Bevan) writes:

>In article <1993Mar25.155650.16244@inmet.camb.inmet.com> 
>  stt@spock.camb.inmet.com (Tucker Taft) writes:
>   [ much that I agree with except for the following ]
>   More important than inheritance (even with type extension), 
>   in my view, is the ability to have multiple implementations of 
>   a given abstraction.  This is what separates an "object-oriented"
>   language (like Ada 9X or C++) from an "abstraction-oriented"
>   language (like Ada 83 or CLU).  In an "abstraction-oriented"
>   language, each abstraction interface has exactly one implementation,
>   and hence all calls on operations of the interface can be
>   statically bound.  
>
>One of my favourite languages, ML, allows multiple implementations of
>a single interface via parameterisation and to some extent so does
>Ada83 via generics.  Can this be reconciled with the above statement?

Good point.  However, a compile-time parameterized 
abstraction, as embodied by an Ada 83 generic, 
cannot provide the dynamic flexibility of the run-time
polymorphism of object-oriented languages, where each object
at run-time identifies its own underlying type.  For example,
try creating a heterogeneous linked list using Ada 83 generics.
You might be able to do it (I always hesitate claiming you *can't*
do something with generics with Robert Eachus around ;-), 
but it will be a lot of work and the result will probably 
not be as "user friendly."

With an object-oriented language, a heterogeneous list
is trivial, since a class-wide pointer can point to an object
of any type in a class of types, while each object in the list
identifies its own "creation" type.

On the other hand, Ada 83 generics provide parameterization
by type, so you can create *homogeneous* lists of any arbitrary
type more easily using a generic "list" abstraction.  
So the capabilities of run-time polymorphism inherent 
in an object-oriented language with "self-identifying" 
objects, and the capabilities of compile-time polymorphism 
inherent in generics (with parameterization by type), 
are complementary to one another.

In Ada 9X, we have actually enhanced the support for generics somewhat,
so as to ensure they work well in combination with tagged
types.  Originally, there were some who thought that generics
would become "passe'" once we added support for OOP, but,
as has been recognized by the designers of both C++ and Eiffel,
generics are still very useful for defining abstractions
that are parameterized by type.  Such abstractions typically 
represent some kind of "collection" (i.e., what is 
traditionally called a "data structure" ;-).

I don't know the full details of ML's support for parametric
polymorphism.  If the objects are self-identifying at run-time, then
I would consider it "object-oriented" in the above sense.
If not, implying that defining heterogeneous linked data
structures is more painful, then it is an "abstraction-oriented"
language based on the above definitions.

>bevan

S. Tucker Taft   stt@inmet.com
Ada 9X Mapping/Revisiont Team
Intermetrics, Inc.
Cambridge, MA  02138

Re: Classes vs Tagged Types - Terminology

[Stephen J Bevan]

In article <1993Mar30.143446.20879@inmet.camb.inmet.com> stt@spock.camb.inmet.com (Tucker Taft) writes:
   >In article <1993Mar25.155650.16244@inmet.camb.inmet.com> 
   >  stt@spock.camb.inmet.com (Tucker Taft) writes:
   >   [ much that I agree with except for the following ]
   >   More important than inheritance (even with type extension), 
   >   in my view, is the ability to have multiple implementations of 
   >   a given abstraction.  This is what separates an "object-oriented"
   >   language (like Ada 9X or C++) from an "abstraction-oriented"
   >   language (like Ada 83 or CLU).  In an "abstraction-oriented"
   >   language, each abstraction interface has exactly one implementation,
   >   and hence all calls on operations of the interface can be
   >   statically bound.  
   >
   >One of my favourite languages, ML, allows multiple implementations of
   >a single interface via parameterisation and to some extent so does
   >Ada83 via generics.  Can this be reconciled with the above statement?

   Good point.  However, a compile-time parameterized 
   abstraction, as embodied by an Ada 83 generic, 
   cannot provide the dynamic flexibility of the run-time
   polymorphism of object-oriented languages, where each object
   at run-time identifies its own underlying type.

But I never claimed they did.  My one objection to the paragraph I
quoted was the characterisation of the difference between
object-oriented and abstraction-oriented being that the former allows
multiple implementations per interface and the latter only allows one.
In the followup you seem to change your position to "self identity"
being the important feature of an "object" claiming to be
object-oriented :-


   I don't know the full details of ML's support for parametric
   polymorphism.  If the objects are self-identifying at run-time, then
   I would consider it "object-oriented" in the above sense.
   If not, implying that defining heterogeneous linked data
   structures is more painful, then it is an "abstraction-oriented"
   language based on the above definitions.

I'm probably being pedantic, but I always think of a hetrogeneous list
as allowing a mixture of types rather than different types derived
from a single root.  Has a term been coined for the pseudo
hetrogeneous structures that most OO languages allow or is the word
"hetrogeneous" forever lost?

bevan

Re: Classes vs Tagged Types - Terminology

[Robert I. Eachus]

In article <1993Mar30.143446.20879@inmet.camb.inmet.com> stt@spock.camb.inmet.com (Tucker Taft) writes:

  > Good point.  However, a compile-time parameterized 
  > abstraction, as embodied by an Ada 83 generic, 
  > cannot provide the dynamic flexibility of the run-time
  > polymorphism of object-oriented languages, where each object
  > at run-time identifies its own underlying type.  For example,
  > try creating a heterogeneous linked list using Ada 83 generics.
  > You might be able to do it (I always hesitate claiming you *can't*
  > do something with generics with Robert Eachus around ;-), 
  > but it will be a lot of work and the result will probably 
  > not be as "user friendly."

     Right way to bet, but you didn't take it far enough. :-)

     Seriously, it is very easy (well, easy for me anyway) to write a
polymorphic list package in Ada 83, you can even have objects and
parameters which would be of type T'CLASS in Ada 9X.  The only problem
is that you have to "hand write" the dispatching which occurs when you
actually try to do something with a value of a class-wide object.
However operations on class wide values whose return values are not of
a specific element type are no problem.

     I could post a toy example here, but if anyone is interested I
wrote something very similar for processing DIANA trees.  (It didn't
even use generics.)  Since most of the dispatching was in the body of
the package (and generated by a tool, I'm no glutton for punishment)
it reduced the size of the code using the package by an order of
magnitude or so over a non-abstract type.

     Don't get me wrong, the addition of tagged types in Ada 9X will
make a lot of things easier, and will provide a lot of functionality
not in Ada 83.  It's just that polymorphic data structures have always
been "in there."  Using them has just never become a normal part of
the Ada culture.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Classes vs Tagged Types - Terminology

[Robb Nebbe]

In article <C4AGp4.1Fw@clw.cs.man.ac.uk>, chl@clw.cs.man.ac.uk (Charles Lindsey) writes:
: 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.
: 

We shouldn't leave Oberon out of this discussion since it is already
available and Ada 9X is still only a proposal. Oberon implements
inheritance for record types and Wirth even goes out of his way to
avoid mentioning the word "tag" when talking about the concepts in his
book. Oberon also rather neatly avoids the distributed overhead incurred
by Ada; objects with a specific type have no need for a tag and so the
only objects that have tags are record pointers which don't necessarily
always point to an object of the same specific type.

Tagged types will probably be a peculiarity of Ada (although certainly
justified in Ada's case) and I don't think we will be seeing other
languages with tagged types.

: Charles H. Lindsey 

Robb Nebbe

Re: Classes vs Tagged Types - Terminology

[David Emery]

>Tagged types will probably be a peculiarity of Ada (although certainly
>justified in Ada's case) and I don't think we will be seeing other
>languages with tagged types.

Modula-3, if I'm not mistaken, uses the same idea as Ada 9X...
				dave

Re: Classes vs Tagged Types - Terminology

[Robb Nebbe]

In article <EMERY.93Mar24191542@dr_no.mitre.org>, emery@dr_no.mitre.org (David Emery) writes:
: >Tagged types will probably be a peculiarity of Ada (although certainly
: >justified in Ada's case) and I don't think we will be seeing other
: >languages with tagged types.
: >
: > Robb
: 
: Modula-3, if I'm not mistaken, uses the same idea as Ada 9X...
: 				dave

Modula-3 provides what they call object types but are really just classes
in disguise. Modula-3 has adopted a whole new vocabulary but doesn't do
anything fundamentally different from all the other "OO" languages such
as Smalltalk, Eiffel, Simula, C++, and Objective C. The purpose of the
Modula-3 vocabulary seems to be to give the appearance that object types
(classes) are well integrated into the type system. This just serves to
cover up the fact that Modula-3 is a hybrid language.

This is to be contrasted with Ada 9X, where the approach is fundamentally different and the syntax reflects this difference.  Ada 9X fully integrates
the new OO features with the old OO features. This approach seems to provide
quite a few advantages and will certainly be a plus for Ada.

The language that comes the closest conceptually to the approach used
in Ada 9X is Oberon. Ada 9X is clearly more powerful, but it seems to me
that in some cases the solution chosen in Oberon is more appropriate
than the solution chosen in Ada 9X; The Ada 9X solution looks a lot like
Eiffel in some ways and I'm not sure if it is appropriate or not. Only time
will tell.

Robb