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

[stt@spock.camb.inmet.com (Tucker Taft)]

In article <1993Mar7.191557.5547@evb.com> jgg@evb.com (John Goodsen) writes:

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

Please note the "smiley."

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

I can feel a religious war coming on...

In Ada 83, the package is the encapsulation/information-hiding construct.
Adding a keyword "class" to "type ... is tagged" wouldn't change
that at all, and the keyword substitution was all that Jean Ichbiah 
was proposing.  In fact, he specifically made it 
clear in his proposal that we should *not* change the encapsulation
rules.  After all, his team designed packages in the first place,
with full knowledge of the "class-based" alternatives present
in Simula-67, CLU, etc.

Using classes for encapsulation works great in some circumstances,
but breaks down in others.  If you are familiar with the
way operators work in C++, and the subtleties having to do
with implicit conversions on the "this" parameter versus the
other parameter (the "that" parameter ;-), the appropriate
use of "friends," etc., you begin to see the places where 
class=module approach breaks down.

Consider a typical definition of a "complex" abstract data type in 
Ada 83 (names of operations can be debated in e-mail):

   generic
       type Real is digits <>;
   package Complex_Numbers is
       type Complex is private;
       function "+"(L, R : Complex) return Complex;
       function "*"(L, R : Complex) return Complex;
     . . .
       function Cmplx(Re, Im : Real) return Complex;
       function Re(C : Compex) return Real;
       function Im(C : Compex) return Real;

       type Imaginary is private;
       i : constant Imaginary;   -- This allows "3.5 + 4.0*i" notation
       function "*"(L : Real; R : Imaginary) return Imaginary;
       function "*"(L : Imaginary; R : Real) return Imaginary;
       function "+"(L : Real; R : Imaginary) return Complex;
       function "+"(L : Imaginary; R : Real) return Complex;
     . . .
   private
       type Complex is record
         Re, Im : Real;
       end record;

       type Imaginary is new Real;
   end Complex_Numbers;

How would you write this in a "class-based" language?
At least in C++, operators almost always have to be made "friends"
to work right.  So much for language-enforced encapsulation.  And 
here we have two types, Complex and Imaginary, that are interrelated,
and are naturally defined in a single package.  One would
have to resort to "friends" or perhaps nesting in C++.

The C++ solution might nevertheless be quite elegant, if structured
properly according to reasonable coding guidelines, using the
file=module model where appropriate.  But in this case, we see
that Ada provides better direct encapsulation support than does
a class-based language.

So for some cases, where most operations have only a single
"interesting" parameter, the class-based approach seems more direct.
In other cases (like the above), the package-based approach
seems more direct and supportive of encapsulation.

In any case, Ada 83 clearly chose the package-based approach, and
we are not trying to change that for Ada 9X.  We felt that there
was no need to force Ada programmers to adopt a different way of
doing encapsulation just to get more support for dynamic binding 
and type extension.

We don't see the need to make Ada 9X a "me too" object-oriented
language.  Instead, we want it to combine the best ideas of
Ada 83 and OO languages, into something that advances the state
of the art, not something that trails just behind always trying 
to catch up.  We believe that this approach makes the most sense, 
both technical, and marketing.  Your mileage may of course vary...

> . . .
>John Goodsen
>EVB Software Engineering

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