Re: Ichibah flames, and flames out over, Ada 9X

Re: Ichibah flames, and flames out over, Ada 9X

[John Goodsen]

stt@spock.camb.inmet.com (Tucker Taft) writes:

>srctran@world.std.com (Gregory Aharonian) writes:
>> . . .From this point of view, the original posting's
>>call for more features in Ada9X that allows better competition with C++
>>(and Smalltalk) should be heeded.
>
>There are many ways to skin a cat.  In many cases, imitation is not
>the most effective strategy.  Why choose Ada 9X if it makes the same
>mistakes that C++ does?  

Which is hardly what I was proposing.  Are you saying that classes
are a mistake in C++ ?  I would hope that the real message of 
the original posting was received as:

  Object Oriented Analysis and Design approaches (most of them
  and certainly the mainstream) use class based approaches.  
  When a software engineer performs OOA and/or OOD, it is going
  to be quite natural to look for an implementation language
  which *has class*.  If you don't make it easy for someone on
  the language search to see that Ada supports the concept of
  "class", then the acceptance of the language for OO development
  will not meet it's true potential.

I have heard the arguments on why tagged types are *better* than
classes, and for the most part agree with them.  This is not a
technical issue.  It's a market acceptance issue.  If the solution
is to change the syntax from "tagged type" to "class" and leave
it at that, then it doesn't sound like too much of a problem and
I will predict that the commercial payoff will be worth the minor
syntactical change.  

I know what you're thinking:  "But, if we change 'tagged type'
syntax to 'class' syntax, it won't be a class in the same
terms as other languages!"  Great!  If you want to introduce the
world to a better object oriented programming mechanism, then
at least speak to the world in their language.  The language
that people will understand is "class", not "tagged type".

A class in CLOS, smalltalk and C++ are not identical already.
The argument that if Ada uses the word "class" then it has
to be exactly like C++'s implementation of a class doesn't
hold water.  Don't let a C++ vs. Ada bias affect this "CLASS"
syntax issue.  It will seriously hinder new market acceptance of
Ada as an OOP language.

>
>We should learn from the strengths and
>weaknesses of other languages, and advance the state of the art, 
>not solidify it around a 1985-vintage design.
>

So is it safe to assume that 9x tagged types are considered
as "advancing the state of the art" by the Ada 9X project or
wasn't the syntax terminology introduced to remain consistent
with the Ada 83 "state of the art".

A serious question, really :-)

-- 
John Goodsen
Software Process & Environments
EVB Software Engineering
jgg@evb.com

Re: Ichibah flames, and flames out over, Ada 9X

[David Emery]

>A class in CLOS, smalltalk and C++ are not identical already.
>The argument that if Ada uses the word "class" then it has
>to be exactly like C++'s implementation of a class doesn't
>hold water. 

What percentage of practicing C++ programmers know CLOS and/or
SmallTalk?  My experience (direct and indirect, including the several
places my wife has worked recently) is "few".  Sure, there are people
who know multiple languages.  In this case, Ada's tagged types would
also be a reasonable concept (akin to Modula-3).  But, for the great
masses of C++ programmers, the word "class" means "C++ class", and I
believe their reaction is "different is wrong".
				dave

Re: Ichibah flames, and flames out over, Ada 9X

[Tom Pole]

In article <EMERY.93Mar10174143@dr_no.mitre.org> emery@dr_no.mitre.org (David Emery) writes:
>>A class in CLOS, smalltalk and C++ are not identical already.
>>The argument that if Ada uses the word "class" then it has
>>to be exactly like C++'s implementation of a class doesn't
>>hold water. 
>
>What percentage of practicing C++ programmers know CLOS and/or
>SmallTalk?  My experience (direct and indirect, including the several
>places my wife has worked recently) is "few".  Sure, there are people
>who know multiple languages.  In this case, Ada's tagged types would
>also be a reasonable concept (akin to Modula-3).  But, for the great
>masses of C++ programmers, the word "class" means "C++ class", and I
>believe their reaction is "different is wrong".
>				dave

I have enjoyed this battle up to this point, without participating.
Now I can't resist the comment. Who Cares (only) what the average C++
programmer thinks. (In this discussion, not in all matters, I have
nothing against C++ programmers, some of my best friends are... etc.)
C++ is not the only OOPL used in software development, nor will it
ever be. If Ada disappears tomorrow (DOD forbid), there will still
be serious development done in Smalltalk, Eiffel, and CLOS.
If Ada is to break into the commercial OOPL market in more than
a token way, it must present the OO programmer with an OOPL, not
just try to compete with C++. Most OO programmers have mutual
respect for each other's favorite languages, AND have a common
shop-talk language to discuss the compartive benefits of each.
This shop-talk includes class, but not tagged types.

If Ada wants to attract/convince/whatever programmers to use Ada, and 
that it is truly an OOPL, then Ada should use the accepted (de facto standard)
terminology of OORequirements Analysis, OODesign, OOetc.

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.

If Ada wants to add the ability to have specialization
but keep it a secret that only Ada initiates understand, then
call it some obscure, uncommon, semantically weak term like tagged
types. There is not a theasaurus in the world that is going to relate
any of the terms class, inhertance, inheritable type, specialization,
or object oriented with the word tagged.

The only other software related use of tagged types I know of refers to 
the tagged types implemented in hardware for Lisp machines. Haven't
heard that term used lately.

Thomas Pole
All opinions are my own, unless I can find someone else
to blame them on.
-- 

Thomas Pole

Re: Ichibah flames, and flames out over, Ada 9X

[Charles H. Sampson]

In article <1993Mar12.160136.6106@evb.com> pole@evb.com (Tom Pole) writes:

>If Ada is to break into the commercial OOPL market in more than
>a token way, it must present the OO programmer with an OOPL, not
>just try to compete with C++. Most OO programmers have mutual
>respect for each other's favorite languages, AND have a common
>shop-talk language to discuss the compartive benefits of each.
>This shop-talk includes class, but not tagged types.
>
> ...
>
>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.

     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.

     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.

				Charlie

re: Classes versus tagged types was Ichibah flames, and flames out over, Ada 9X

[Tom Pole]

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

Classes, objects and instances are not three different terms for
a single concept. One noted OO expert's graphic presentation
excepted, classes and objects are two different concepts. (No I'm
not talking about Booch).

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.

An instance of a class is an object that is of that class, and
defined at least in part by inheriting state and functionality
from the class definition.

An object need not be an instance of a class, see Ada. An instance
is a kind of object that is defined at least in part by its class.

I could polish those definitions a little, but almost all
(there are always flames to be ignited) C++, Eiffel (did I
misspell it again ?), Smalltalk, CLOS, etc programmers
will understand the meanings of these terms.

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. 

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


-- 

Thomas Pole

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

[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

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

[Larry M. Jordan]

I've been refraining from making the following simple suggestion
primarily because I'm not completely familiar with the proposed
OO extensions for Ada9X and did not want to expose my ignorance
(it won't be the first time). But here goes anyway:

If 'tagged types' are identified as such because they are now
extensible and can have class-wide operations associated with them,
why not replace 'tagged' with 'extensible'?  So what if it's harder to
spell. This seem more straightforward, enhances understanding
(would have mine anyway), removes the ugliness otherwise associated 
with the term 'tagged'.

If this has been suggested before, sorry to waste everyone's time.

--Larry

Re: Ichibah flames, and flames out over, Ada 9X

[Keith Thompson @pulsar]

In article <1993Mar12.160136.6106@evb.com> pole@evb.com (Tom Pole) writes:
> [...]
> If Ada wants to attract/convince/whatever programmers to use Ada, and 
> that it is truly an OOPL, then Ada should use the accepted (de facto standard)
> terminology of OORequirements Analysis, OODesign, OOetc.
> 
> 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.
> [...]

Many years ago, when I first read the preliminary Ada reference manual
(the 1979 version), I had a lot of trouble understanding the section
on access types, with its discussion of access values "designating"
objects and so forth.

Not long after that, I realized that access types are (essentially)
what Pascal calls pointer types.  (Pascal was the language I was most
familiar with at the time.)  The current (1983) Ada reference manual
has a note explaining that "Access values are called pointers or
references in other languages" (3.8:10); the 1979 preliminary version
probably had a similar note, but I missed it at first.

Once I had made that connection, I didn't have any problem understanding
what access types are and how they work; most of what I had learned about
Pascal pointer types applied almost directly to Ada access types.

My point is that these minor differences in terminology (pointers vs.
access types, classes vs. tagged types, functions returning void vs.
procedures) really don't matter.  It should take literally no more than
a few seconds to make the connection between similar features in
different languages, once the correlation is pointed out.

Furthermore, as others have mentioned, a C++ class is both a type and a
unit of encapsulation.  The Ada equivalent of a C++ class would be a
package containing declarations for a single type and its operations,
but Ada also allows declarations of any set of logically related
entities to be grouped into a package.  In my opinion, this is a
considerable advantage of Ada over C++.

Ok, so I'm simultaneously arguing that the difference in terminology
doesn't matter because the constructs are the same, and that the
terminology should be different because the constructs are different.
You expect consistency in a Usenet posting?  8-)}

Seriously, I believe that Ada 9X tagged types provide essentially the
same capabilities as C++ classes, in a way that fits well into the
existing Ada 83 framework of packages, derived types, and so on.  I see
little point in making the purely syntactic change from "type Foo is
tagged record ..." to "class type Foo is record ...".  Any more
extensive change, like making classes a unit of encapsulation, would do
too much violence to the overall structure of the language.

The Ada 9X reference manual should probably have a note pointing out
the correlation between tagged types and the various class constructs
of C++ and other object-oriented languages.
-- 
Keith Thompson (The_Other_Keith)  kst@telesoft.com
TeleSoft^H^H^H^H^H^H^H^H Alsys, Inc.
5959 Cornerstone Court West, San Diego, CA, USA, 92121-9891
"Listen to me, people!  We must stick them with quills -- it's the only way!"

Re: Ichibah flames, and flames out over, Ada 9X

[Fergus James HENDERSON]

kst@telesoft.com (Keith Thompson @pulsar) writes:

>I see little point in making the purely syntactic change from "type Foo is
>tagged record ..." to "class type Foo is record ...".

Marketing.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!

Re: Ichibah flames, and flames out over, Ada 9X

[Harry Koehnemann]

In article <1993Mar13.031104.21673@telesoft.com> kst@telesoft.com (Keith Thompson @pulsar) writes:
>
>Once I had made that connection, I didn't have any problem understanding
>what access types are and how they work; most of what I had learned about
>Pascal pointer types applied almost directly to Ada access types.

And look how the word "access" has completely removed "pointer" or
"reference" from existence in the CS world :).  But really, why take a
very well understood concept and name it something completely off the
wall.  Didn't Ada desire to facilitate understanding, rather than get
in it's way?

>My point is that these minor differences in terminology (pointers vs.
>access types, classes vs. tagged types, functions returning void vs.
>procedures) really don't matter.  It should take literally no more than
>a few seconds to make the connection between similar features in
>different languages, once the correlation is pointed out.

This of course is not true.  The mapping between a Pascal "pointer"
variable and an Ada "access" variable is well understood.  Only minor
semantic differences exist between the two.  However, no such mapping
exists between a Smalltalk/Eiffel/C++ "class" and an Ada "tagged type/
package/generic/task" (objects with separate threads of control).

I'll contend that translating an OO design into the Ada paradigm is not
a straight forward activity for someone raised on these other languages
(if it is a straight forward activity at all).  It is certainly not as
trivial as making the transition from pointers to access types (if you
can call "access" = "pointer" a transition).

>The Ada 9X reference manual should probably have a note pointing out
>the correlation between tagged types and the various class constructs
>of C++ and other object-oriented languages.

This is not as simple as it might seem and if anything would probably
do more harm than good.  If you're going to use a new paradigm, learn
it, understand it, and *then* build smoething in it.  Don't take the
cheesy way out and use some mechanical translation algorithm without
understanding what's being created.  I can already see the subject
line: "Wanted C++ to Ada9X translator".  I'd love to see that Ada code.

>-- 
>Keith Thompson (The_Other_Keith)  kst@telesoft.com
>TeleSoft^H^H^H^H^H^H^H^H Alsys, Inc.
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Now that's funny.
--
Harry Koehnemann			Arizona State University
koehnema@enuxha.eas.asu.edu		Computer Science Department

Re: Ichibah flames, and flames out over, Ada 9X

[Michael Feldman]

In article <1993Mar15.231916.16276@ennews.eas.asu.edu> koehnema@enuxhb.eas.asu.edu (Harry Koehnemann) writes:
>
>I'll contend that translating an OO design into the Ada paradigm is not
>a straight forward activity for someone raised on these other languages
>(if it is a straight forward activity at all).  It is certainly not as
>trivial as making the transition from pointers to access types (if you
>can call "access" = "pointer" a transition).
>
C'mon, guys. Have you ever tried to get a Fortranner to understand
records?  It's not easy but eventually they get it. Have you ever tried
to explain to a Fortranner why Ada does not require that 2-d arrays be
mapped column-by-column? Sure it's a transition, but so what?

If in fact an OO design (in the C++ sense) can't be mapped easily into
Ada9X (and I am still waiting for a real demonstration that this is so),
where is it written that the C++-oriented design was the right one?
Read Rosen's paper on composition vs. class hierarchies (CACM 11/92).

Each new generation of languages brings with it a new set of terms and
a somewhat changed paradigm. Programmers who are raised on Ada have no
trouble with Ada terminology. And the others - IF they are open-minded -
learn it eventually. I've taught Ada to maybe a thousand industry folks
and maybe two thousand university students, and I'm persuaded from that
10 years of experience that an open mind is the most important 
prerequisite. Old Fortran programmers will learn to use Ada well IF
they so desire. Young, geeky C types will not, IF their minds are closed.

So what else is new? Openminded people learn more.

The point of the OO changes to Ada9X was to add new technology to the
language. Technical considerations presumably were more important than
marketing ease. I think Tucker has made the case for tagged types
as a _smooth_ extension from Ada83 and classes as a rather messier one.
Dontcha think it's time to just quit trying to fight a losing battle?
Ada9X-style OOP is in the language. Quit trying to make Ada9X look like
C++, Eiffel, or what have you. Go back to work already.

I am STILL waiting to see a _real_ example of a design of a _real_ system
that is better enough in C++ than it is in Ada to make it worth all this
fuss over terminology. We all know that tagged types vs. classes is NOT
the reason why Ada9X will fail (if indeed it will fail). I'm not going
into all that again.

It's much easier just to trash Ada than to come up with a design that
shows the flaws.

Cheers -

Mike Feldman

Re: Ichibah flames, and flames out over, Ada 9X

[Robert Firth]

In article <1993Mar15.231916.16276@ennews.eas.asu.edu> koehnema@enuxhb.eas.asu.edu (Harry Koehnemann) writes:

>And look how the word "access" has completely removed "pointer" or
>"reference" from existence in the CS world :).  But really, why take a
>very well understood concept and name it something completely off the
>wall.  Didn't Ada desire to facilitate understanding, rather than get
>in it's way?

I'll answer that.  The main reason we used "access" instead of "pointer"
is that "access" is a semantic concept at the level of the language, while
"pointer" is an implementation technique at the level of the underlying
machine.

We had seen the hideous confusion this mistake had caused in other
languages, leading to wrong code, unmaintainable code, and non-portable
code.  Examples of false assumptions caused by the "pointer" terminology
include

	. an access value is a machine (hardware) address
	. an access value and an integer are interconvertible
	. access values with different base types are interconvertible
	. all access values are the same physical size
	. arithmetic on access values can be used in lieu of proper
	  high-level iterators

To anyone familiar with Ada, these propositions are blatantly false.
Replace "access" with "pointer" and they remain false, but almost
invisibly so.

One goal of Ada was reliable programming.  In our opinion, the use of
"pointer" terminology was a major source of almost ineradicable design
and implementation errors in much then current software.  I believe
history has vindicated us.

Robert Firth

Re: Ichibah flames, and flames out over, Ada 9X

[Anthony Howell]

In article <EMERY.93Mar10174143@dr_no.mitre.org> emery@dr_no.mitre.org (David Emery) writes:
>
>What percentage of practicing C++ programmers know CLOS and/or
>SmallTalk?  My experience (direct and indirect, including the several
>places my wife has worked recently) is "few".  Sure, there are people
>				dave

Just to let you know, I teach Smalltalk programming in our company (Hughes Aircraft) to
help the people make the paradigm shift to OOT and then we teach them C++ for the
real stuff in our area.  (True there are ADA 9X advocates here, but I am not one of them.)

Tony Howell

Re: Ichibah [sic] flames, and flames out over, Ada 9X

[Magnus Kempe]

In article <1993Mar10.201515.6295@evb.com>, jgg@evb.com (John Goodsen) writes:
: If you don't make it easy for someone on the language search to see
: that Ada supports the concept of "class", then the acceptance of the
: language for OO development will not meet it's true potential.

In Ada 9X, you will be able to declare e.g. class-wide objects and
access types, such as:

	type Stack_Ref is
	  access Stack'class;
	
	A : Stack'class;

Is it easy enough to see that Ada 9X has "class" ?


: If the solution is to change the syntax from "tagged type" to
: "class" and leave it at that, then it doesn't sound like too
: much of a problem...

Contrary to OOP languages where objects per se are polymorphic,
Ada objects are monomorphic since Ada has by-value semantics.
Ada 9X programmers will _also_ be able to manage by-reference
semantics to have polymorphic references to objects, which is
what other OOP languages really provide.  Generally, a class
declaration in an OOPL implies that instances may belong to
the class itself or to a subclass, and that they are polymorphic;
in consequence, OOPLs rarely perform any significant amount of
strong, static type checking.

You don't want to throw away Ada's strong type system and static
checking, do you?

Anyway, I doubt that the adoption of Ada 9X will rest on the ability
of C++ programmers to grasp that "tagged" is somehow an equivalent of
their "class".  I don't think they will, since most C++ programmers
that I know enjoy C++ "because it's compatible with C".  Ada is
incompatible with C-oriented minds.  And that's a Good Thing.

If you want to learn of the many problems with C++, go read
  "C++?? A Critique of C++", Ian Joyner (e-mail: ian@syacus.acus.oz.au)
  "A Critique of the Inheritance Principle of C++", Markku Sakkinen,
  in Computing Systems, Vol. 5, No. 1, Winter 1992
  "The Darker Side of C++ Revisited", Markku Sakkinen,
  in Structured Programming (1992) 13: pp. 155-177.
(Warning: Referenceless flames and other hate-mail ignored on principle :-)

-- 
Magnus Kempe                "No nation was ever drunk when wine was cheap."
magnus@lglsun.epfl.ch                                   -- Thomas Jefferson