Re: Ada OO Mechanism

[Richard D Riehle <laoXhai@ix.netcom.com>]

In response to my example showing array handling in Ada versus
C++, 

>Hyman Rosen <hymie@prolifics.com> writes:
>> ...and follows up with code demonstrating the superiority of Ada
>> array handling over the C++ version.
>[...]
>> Array indexing, however, does not normally fall under the heading
>> of object-oriented techniques.

 Yes, I suppose that is true.  Array management and implementation
 details of other container classes is more the province of programming
 than object-oriented programming.  However, someone once said, "The
 Devil is in the details."   Since part of this discussion began as
 a question regarding the C++ versus the Ada generic in OOP, perhaps
 it is instructive to note that the array example is not completely
 unrelated to the original quest, especially when one considers the
 details. 

 Nevertheless, the above point will not satisfy those with a need for
 more OO specific examples.  So I will take some time and return to
 my software greenhouse to grow some additional examples, especially
 since my email has explicitly encouraged me to continue the
 "bladder purging" contest.  

The examples will not appear instantaneously since I do have to devote
a small portion of my workday to actual work.  One idea that occurred
to me driving to work this morning was a nice feature of Ada that
allows me to overload a function based on return type and use that
return type as a controlling result for dispatching.  Also, the ability 
to create functions that return a classwide type.  The value of those
features could be lost on someone not familiar with Ada, but they serve
as powerful design mechanisms.

For example, in the same scope and visibility

         type T is tagged ...
 
         function Get(F : some-file) return T;
         function Get(F : access some-file) return T;
         function Get(F : some-file) return T'Class;

         type B is new T with ...

         function Get(F : some-file) return B;
         function Get(F : access some-file) return B;

         
 where the two type specific Get's are dispatching operations
 and the return type resolves the overloading.  This is not
 possible in C++ and it limits certain design decisions.  There
 are dozens of these kinds of examples.  It is interesting that
 this example also extends itself to the design of templates and
 makes Ada a little more flexible.

 One of the original contentions was that, although the C++ model of
 
             class <=> type <=> module

 appears to be simpler on the surface, as one begins to design large
 scale software, that model becomes something of a straightjacket. It
 utltimately requires friend functions and other encapsulation-breaking
 features (such as the new "mutable" reserved word) to get around the
 restrictions imposed by such a small model of object-oriented 
 programming.  

 On the positive side, this same model has been used by Eiffel more
 successfully than by C++.  This is probably because Eiffel did not
 begin with the need to counter side-effects inherited from C.  In 
 the new ISO C++ standard, many of those side-effects have been 
 eliminated by proscribing some of the more dangerous features of C.
 However, Java, C++ and Eiffel all fail to explicitly separate the
 contract from the implementation.  

 Separation of the contract from the implementation, while an option
 in C++, is not always desirable for technical reasons.  This separation
 of contract from implementation is a far more important feature for
 good object-oriented programming than making the class and type and 
 module the same unit.  

 I will try to create some coded examples in the coming week.  I hope 
 others will also contribute to this thread.  Even though the comparison
 of languages is often considered fruitless, I am beginning to believe
 it is important.  Why?

 More and more of our DoD clients are making the mistake of choosing C++
 instead of Ada for critical software.  I think it is important that
 such decisions be made on the basis of good information.  When the two
 languages are examined in depth, I have no doubt that an informed
 management would realize the benefits of Ada over C++.  Sadly, too
 many of these decisions are being made on the basis of what seems to
 be rather than what really is.

 Richard

 Richard Riehle
 richard@adaworks.com
 http://www.adaworks.com