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

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: In favor of tagged types (was Classes versus tagged types was Ichibah flames, and flames out over, Ada 9X)

[John Goodsen]

<1993Mar18.172630@lglsun.epfl.ch> barbey@lglsun.epfl.ch (Stephane Barbey) writes:

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

Exactly my point! :-) Talk to potential new users of Ada 9X in terms
they *understand* and then explain how the Ada 9X "CLASS" is *better*,
but don`t create an extra step by first educating newcomers on new and
non-standard terminology like "tagged types" before you even get to
the "my class is better than your class" discussion.

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

Bad conclusion.  *EVERY* (respectable) OO language has the concept of CLASS
and it is directly supported in the syntax of that language.

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

This is not too tough to conclude, and no one in their right mind
will disagree.  Again, for the nth time (reuse? :-) this is *NOT* the point!
It is strictly a marketing issue.  Don't use "tagged type" terminology.
Use "class type" terminology, so that the marketing folks of Ada 9X 
will be on a level playing field as the competition.  It is only a syntax
modification to the current proposal.  NO SEMANTIC CHANGES WHATSOEVER!


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

With both "tagged type" *AND* "class type" proposals, I might add.
"Class types" will just make it easier for us to make inroads into
NEW, repeat NEW markets, unless we'd rather just hang out in DoD land
and see what mandated Ada 9X contracts come around....


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

You're making up terminology here.  These are considered "types" in Ada XX.


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

Huh?  First you say they're Ada 9X doesn't have a class, and now
you're calling them a class.  Well, I don't blame you.  EVERY OO
Language should have some CLASS, and it sounds like underneath it all,
you agree.


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

"class types" would be more user friendly and less threatening to
the new Ada programmer (read: NEW MARKETS :-)

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

For example?  Are you referring to the proposal for tagged pointers
in C++ that was posted on comp.lang.c++ months ago?

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

That's the point, once again:  "AS LONG AS YOU CARE TO STUDY IT..."
Face the facts.  The world is full of lazy programmers.  Make it easy
for them to see the power.  Don't force them to work at it or too 
many will just bypass it.  Yes this is unfortunate, but it's reality.

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

Still? :-)



-- 
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: In favor of tagged types (was Classes versus tagged types was Ichibah flames, and flames out over, Ada 9X)

[Alex Blakemore]

I just know I am going to regret joining in this thread :-;)

barbey@lglsun.epfl.ch (Stephane Barbey) writes:
>  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. 

jgg@evb.com (John Goodsen) writes:
> You're making up terminology here.  These are considered "types" in Ada XX.

Actually Stephane is correct here. There is a precise definition of
a class in Ada - it is a SET of types (that is closed over derivation).
He is not making up terminology. It is a useful concept, corresponding in 
other languages to the idea "a class and all its subclasses".

In NeXT's Objective-C, there are methods isMemberOf: and isKindOf: that
query whether an object is a member of class A or a member of A or one
if its subclasses.  This shows that some OO users find it useful
to make the distinction between what in Ada9X is called a specific type
and a class wide type.

I tend to trust the MRT on this syntax issue.  Once you understand what
class means in Ada9X, it would be misleading in a big way to replace
the keyword tagged with the keyword class.  Extensible would be nice, but
does not suggest the extra overhead that tagged implies.  I'ld rather have the
language syntax be very explicit about possible overhead.

Ada9X does have classes and it does use the word class prominently in
the syntax.  Its model is somewhat different than other OO languages, but
self consistent.  I think I understand the other OO languages better
now after seeing Ada9X - it is less easy to grasp Ada9X OO at a glance though.

Lets give the issue a rest please. We all understand how you feel John and
your points have justification.  But its not a fatal flaw.  There is enough
class in Ada9X to allow it to prosper, if it is presented well to people with
open minds.  If someone is so close minded that they refuse to try Ada9X,
based on this syntactical issue then it really doesnt matter.
Someone like that would find some other reason to avoid Ada anyway -
perhaps just the fact that the DoD sponsored it.

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

> Huh?  First you say they're Ada 9X doesn't have a class, and now
> you're calling them a class.

John, please read the mapping spec again. Ada9X does have classes and
in fact I think it is an advance in some way to explicitly name the concept
"hierachy of classes rooted at type T". 

-- 
---------------------------------------------------
Alex Blakemore alex@cs.umd.edu   NeXT mail accepted

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

[John Goodsen]

alex@cs.umd.edu (Alex Blakemore) writes:

>Actually Stephane is correct here. There is a precise definition of
>a class in Ada - it is a SET of types (that is closed over derivation).
>He is not making up terminology. It is a useful concept, corresponding in 
>other languages to the idea "a class and all its subclasses".

I stand corrected, to a degree, that is...  After reading the LRM,
there is the terminology "class of types".  You might call these
classes, but really, they are "a class of types".  The subtle 
difference is important to comprehend, because it is being used
as the basis for a fallacious argument.


>He is not making up terminology. It is a useful concept, corresponding in 
>other languages to the idea "a class and all its subclasses".
>

>In NeXT's Objective-C, there are methods isMemberOf: and isKindOf: that
>query whether an object is a member of class A or a member of A or one
>if its subclasses.  This shows that some OO users find it useful
>to make the distinction between what in Ada9X is called a specific type
>and a class wide type.
>

In fact, some excellent articles have been written which discuss the
need for both "TYPES" (including classes of types) and CLASSES within
a language.  See the Bertrand Myers slew of articles that get shipped
to you when you inquire on Eiffel, for an "instance" of these articles :-)

>I tend to trust the MRT on this syntax issue.  Once you understand what
>class means in Ada9X, it would be misleading in a big way to replace
>the keyword tagged with the keyword class.  

Let's get back to the *real* terminology proposal, and not confuse it
with what I just read above...  current Ada terminology discusses 
"classes of types" not "classes". 

>Extensible would be nice, but does not suggest the extra overhead
>that tagged implies.  I'ld rather have the language syntax be very
>explicit about possible overhead.   

It's pretty standard to assume that overhead is incurred in classes
and inheritance.  This is usually the first argument people use
against OO languages. (until they see that they will hand-code this
*overhead* if the language doesn't give it to them directly).
Therefore, using the terminology "class type T is..."  instead of
"Type T is tagged ..."  will still imply overhead.  Remember the big
point is to give (non-technical) people the "CLASS" terminology to use
in literature which will be written concerning Ada 9X.  "Tagged Type"
will cause more confused readers than 9X converts.  The point is, once
again, use terminology which the norm of the community will relate to,
namely the terminology of "CLASS" and *THEN* show how the Ada 9X CLASS
TYPES are *better* than classes in other languages.

>Ada9X does have classes and it does use the word class prominently in
>the syntax.  

Prominently (via the 'CLASS attribute) but not consistently.
It takes a mind shift (albeit small once your versed in the syntax)
to correlate "Type T is tagged ..." and the 'CLASS attribute.
It would be more consistent to correlate "Class Type T is ..." 
with the 'CLASS attribute.

>Its model is somewhat different than other OO languages, but
>self consistent.  

Not self-consistent in the syntax sense, see above...

>I think I understand the other OO languages better
>now after seeing Ada9X - 
>it is less easy to grasp Ada9X OO at a glance though.
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Thank you for making the point again.  Tagged type terminology DOES
make the OO features of 9X hard to grasp at first glance.  The point
is that we can make it simpler to grasp at a glance through the
consistent, meaningful, *common* terminology of "Class Types" instead
of "Tagged Types".

>
>Lets give the issue a rest please. We all understand how you feel John and
>your points have justification.  But its not a fatal flaw.  
>

Well, I'm keeping a tally on this thread, and right now, more people
have sided with the "class type" than "tagged type" syntax.  I've also
received a lot of private email from well-respected individuals in the
Ada community who side with the "class type" syntax, so it seems this
issue is more important not to brush aside so thoughtlessly.

If this news thread is making you think twice about accepting
consufing, non-standard terminology in an important area of the
language, then  Good! That is exactly what it is meant to do.  If it just
plain annoys you, then you might use a KILL file.  

>There is enough class in Ada9X to allow it to prosper, if it is presented well to people with
>open minds.  If someone is so close minded that they refuse to try Ada9X,
>based on this syntactical issue then it really doesnt matter.

It's not that they would be close minded.  It's that you've got to
make it dirt simple and obvious that Ada supports the notion of class
and inheritance.  "tagged types" syntax is not going to help one bit.

Once again:  (reuse at work?:-)

   "The issue is a marketing issue, not a technical issue."
   "Market expansion requires that we talk in a language that the rest
    of the community understands.  CLASS *is* this terminology.
    TAGGED TYPES are not."

These opinions are re-usable...

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

Assignment Overload in Ada-9X

[Jack Beidler]

I recently received a copy of the "Ada 9X Project Report dated
February 1993.  On the top of page 48 in this report there is a
statement about overloading assignment, specifically,

	".., in the case of non-limited control types, assignment
	can be redefined by the user."

I curious about the form of the overload.  Is it soomething like

procedure ":=" (Left : in out Some_Type ; Right : in   Some_Type) ?

or have I misread this statement?
-- 
+------------------------------------------------------------------+
|  John (Jack) Beidler				                   |
|  Prof. of Computer Science Internet: BEIDLER@JAGUAR.UOFS.ED      |
|  University of Scranton              beidler@guinness.cs.uofs.edu|
|  Scranton, PA 18510	      Bitnet : BEIDLER@SCRANTON            |
|                                                                  |
|          Phone: (717) 941-7446	 FAX:   (717) 941-4250     |
+------------------------------------------------------------------+

Re: Assignment Overload in Ada-9X

[Mark A Biggar]

In article <11815@prijat.cs.uofs.edu> beidler@guinness.cs.uofs.edu (Jack Beidler) writes:
>I recently received a copy of the "Ada 9X Project Report dated
>February 1993.  On the top of page 48 in this report there is a
>statement about overloading assignment, specifically,
>	".., in the case of non-limited control types, assignment
>	can be redefined by the user."
>I curious about the form of the overload.  Is it soomething like
>procedure ":=" (Left : in out Some_Type ; Right : in   Some_Type) ?
>or have I misread this statement?

Not really, the report just doesn't go into enough detail.  You don't get
to actually override ":=", what you get to override are the underlying
routines: INITIALIZE, CLONE and FINALIZE.

INITIALIZE is used to prepare the left hand side for assignment,
CLONE is used to actually create the copy of the right hand side,
and FINALIZE is used to destroy the overwritten left hand side.

FINALIZE is also used when a controlled type goes out of scope.
A controlled type is any type derived for the system defined tagged type 
CONTROLLED.

See the ILS for more detail.

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

Re: Assignment Overload in Ada-9X

[Robert I. Eachus]

In article <11815@prijat.cs.uofs.edu> beidler@guinness.cs.uofs.edu (Jack Beidler) writes:

  > I recently received a copy of the "Ada 9X Project Report dated
  > February 1993.  On the top of page 48 in this report there is a
  > statement about overloading assignment, specifically,

  >	   ".., in the case of non-limited control types, assignment
  >	   can be redefined by the user."

  > I curious about the form of the overload.  Is it something like

  > procedure ":=" (Left : in out Some_Type ; Right : in   Some_Type) ?

  > or have I misread this statement?

     No, it is not.  And yes, you have misread the statement: control
should be controlled, but that is a detail.

     The way it works is that there are three operations inherited by
non-limited controlled types from the root type: INITIALIZE, FINALIZE
and CLONE.  (Well CLONE in ILS 1.2, I believe Tucker intends to change
the name.)  In any case, by redefining these operations when deriving
from CONTROLLED, you can obtain the effect of modifying assignment.
Of course, when defining these procedures, there are a lot of
operations on the new type that will cause indefinite recursion, etc.
But used properly, it allows for nice packaged abstractions where
assignment does all the special things required.  For example, it is
(relatively) easy to define a reference-counting type or a general
garbage collected type using this mechanism.

     Actually, now that this feature is relatively stable, I may post
those examples for experts to shoot at.  In either case it it about 20
lines of very sophisticated code that looks simple.  It might even be
a good idea to have both of these classes (oops! :-) as child packages
in the standard.


--

					Robert I. Eachus

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