From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e5eb8ca5dcea2827 X-Google-Attributes: gid103376,public From: Richard D Riehle Subject: Re: Ada OO Mechanism Date: 1999/05/26 Message-ID: <7ihf6i$4hv@dfw-ixnews10.ix.netcom.com>#1/1 X-Deja-AN: 482413829 References: <7i05aq$rgl$1@news.orbitworld.net> <7i17gj$1u1k@news2.newsguy.com> <7icgkg$k4q$1@nnrp1.deja.com> <3749E9EC.2842436A@aasaa.ofe.org> <7id2eo$fag@drn.newsguy.com> <3749FF7D.F17CE16A@aasaa.ofe.org> <374AC676.F7AE0772@lmco.com> <7ieuja$5v9@news1.newsguy.com> <7ifd6l$bmf@sjx-ixn1.ix.netcom.com> Organization: Netcom X-NETCOM-Date: Wed May 26 1:40:18 PM CDT 1999 Newsgroups: comp.lang.ada Date: 1999-05-26T13:40:18-05:00 List-Id: In response to my example showing array handling in Ada versus C++, >Hyman Rosen 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