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

[jgg@evb.com (John Goodsen)]

>In article <1993Feb25.170827.2178@ennews.eas.asu.edu> 
  stt@spock.camb.inmet.com (Tucker Taft) writes:

>>. . . I hear all this hype about tagged types 
>
>I'm glad to know that at least we are getting some "hype" out
>on Ada 9X.  As any good marketer knows, publicity of any kind is often
>better than no publicity at all. ;-)
>

*often* but not *always*.  In the case of this news thread, the 
"hype" is not helping the perception of Ada 9X in a positive manner...


>> . . . and I see a 
>>few small examples of how they're used with packages/generics/..., 
>>but has anyone implemented a few OO problems with each and compared 
>>them? Semantically, it was easier to add extensiosn to Ada than a 
>>class construct.  But, I think the jury's still out on the "type 
>>extensions 
>> classes" question.  
>
>Actually, there really is not that much difference.  A class-based language 
>happens to have type = module, whereas in package/module-based languages, 
>types are declared inside of modules.
> 

Actually, there's nothing saying that you can't have *MORE* than one
class per module (Ada package) in a class based language.  The class
supports the logical encapsulation of data and operations on that data
(which is the norm in the OO community).  Ada packages would provide
the capability to group related classes and nested classes.

What's the *real* problem with introducing the keyword "class"
instead of "type ... is tagged" ?!?!? 

The tagged type extension doesn't provide the logical encapsulation
mechanism for the associated operations.  So if I *do* add more
than one class (tagged type) to a package, where's the logical
encapsulation of the operations that can be performed on that type?
Leave it up to the programmer to place them in close proximity?
Add more rules to coding guidelines to ensure it?  I'd rather have
the language enforce it...

Is it really that painful to bite the bullet and add the keyword
"class" to the Ada language.  This simple addition to the current
9X approach will provide vendors such as us with a lot more
"perceptual power" to lobby the OO community to seriously look at
using Ada rather than languages such as C++ on their projects.
Once again I'll state it:  

   A *PERCEIVED* feature of an Object Oriented language is that
   it provides a class mechanism with polymorphic behavior.

If Ada 9X comes out without direct support for the concept of class,
then it will have trouble being *PERCEIVED* as a *real* OO language
and you can kiss all those new OO markets bye-bye.

It doesn't matter if I can *achieve* it with tagged types, the simple
fact of the matter is that most people won't dig deep enough into the
concept of tagged types to understand that this is where their
class/inheritance/polymorphism support is embedded.  They will end up
choosing languages like C++ which provide *direct* support for the
class concept.

What do we mean by *direct* support for the class concept?  Simple:

   Add the keyword "CLASS" to the language already !!!

Heck, you've already got the 'CLASS attribute in the language!  Is it
really that much more effort to use "CLASS" instead of 
"TYPE ... IS TAGGED" ???

I'm getting the feeling that the real reason for not adding CLASS to
the language is an extreeeeeeeeeme case of the "Not Invented Here"
syndrome.  In this case the NIH syndrome will hurt the marketing of
Ada as an OO language worse than anything else I can think of
(including the lack of direct support for multiple inheritance, which
is another issue :-)

>If you only declare one type 

   ... [talk about one type per module ]...

>
>But in any case, the debate between Jean Ichbiah and the 
>Ada 9X Mapping/Revision Team (MRT) was not really about 
>"classes" vs. "type extensions," it was whether we 
>should use the keyword "class" in the syntax for type extensions.
>

From reading the above, you can see that my vote is with Mr. Ichbiah...

>The MRT felt that it would simply further confuse the issue by trying
>to cloak our type extensions in the word "class."  
>

"Cloak" ?? Hmmm, so what you're saying is that Ada 9X truly doesn't
have a "class" concept but rather it is a "type extension" ?

>
>So the issue was really about which syntax was most suggestive of the 
>semantics --a kind of issue that unfortunately does not lend itself to 
>objective debate, even though it creates strong feelings on both sides.
>

How about a debate which includes $$ and cents in the marketing
of the language.  Too much technical focus and not enough
market focus on the OO support of Ada 9X will come back to haunt
us ...

>
> . . . People seem to use what they like and OO developers like a
>class construct.  Tagged types are not new and for some reason or
>another were never embraced by the OO community.
>

 ... [ more talk about types inside modules ] ...

>
>Despite the enormous success of C++, there is still a lot of (at least 
>academic) interest in the new OOP languages Modula-3 and Oberon-2, both 
>of which have gone the type-inside-module.  So it may be too early to say that
>"we have a winner."  
>

As the C++ market doubles each year, I don't think there is much
debate who the "winner" will likely be.  C++ has already layed out
most of commercial market battle field for OO languages in the next 10
years.  Wouldn't it be nice to say that "Ada has everything C++ has
*PLUS* tasking, hierarchical libraries, etc..."?  Ada 9X has got to
directly match the class concept of C++ or it will lose too many
potential users to a language which supports it.

When people read an OOD book and it talks about "classes",
"inheritance" and "polymorphism", they will naturally look for these
constructs in a language.  The majority of these people will bypass
Ada 9X when they see that it doesn't have direct support for "classes"
(unless this advice is heeded and the tagged types are changed to
classes :-)


>And for that matter, once you start using one
>of these languages, you will probably discover the type=module vs.
>type-inside-module choice has very little effect on how you design
>and structure your OOP systems.  You will end up creating groups of
>types whether or not the language directly supports the concept of
>"modules."  Similarly, you will often end up having one (primary) type 
>in a module, even if the language allows multiple such types.
>The structure of the problem will probably have more effect on 
>the structure of the program than does the type=module vs. type-inside-module
>decision of the language designer.
>

All the more reason to allow multiple CLASSes in an Ada package?
(which tagged types gives us).  Now all we need to do is make them
look like a class instead of a "tagged type".  Then we've got the best
of both worlds! :-)

Leave Ada types and subtypes as they are in Ada 83.  They serve their
purpose just fine.  Don't confuse them with classes and inheritance.

>> . . .Should be an
>>interesting next few years.
>
>No debate there.
>

It would be even more interesting if Ada 9X became a *real*
commercial competitor of C++ !!!  

  CLASS!  CLASS!  CLASS!

If you don't have class, you won't be considered an OO language!!!
I doubt many reading this c.l.a newsgroup want to hear:

   "Ada's a nice language, but it doesn't have any CLASS!"

:-)



EDITOR'S NOTE: 

  There's more to changing "TYPE ... IS TAGGED" to "CLASS" than
  addressed in this post.  In particular the syntax and semantics of
  encapsulating functions/procedures within a class are left as
  excercise to the MRT. :-) Once again I'll point to Colin Atkinson's
  book on DRAGOON as an excellent example on how to do it...



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