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

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

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