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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,7251fa99aab97e06 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1993-03-09 10:12:31 PST Newsgroups: comp.lang.ada Path: sparky!uunet!zaphod.mps.ohio-state.edu!howland.reston.ans.net!gatech!ncar!csn!csn!arrayb!wicklund From: wicklund@intellistor.com (Tom Wicklund) Subject: Re: Ichibah flames, and flames out over, Ada 9X Message-ID: <1993Mar9.181231.27197@intellistor.com> Organization: Intellistor, Inc. References: <1993Mar7.191557.5547@evb.com> <1993Mar8.153639.3603@inmet.camb.inmet.com> Date: Tue, 9 Mar 93 18:12:31 GMT Date: 1993-03-09T18:12:31+00:00 List-Id: In <1993Mar8.153639.3603@inmet.camb.inmet.com> stt@spock.camb.inmet.com (Tucker Taft) writes: >I can feel a religious war coming on... I don't want to start a religious war, but I think Mr. Taft's experience with C++ is too limited. On the other hand, I've never done any real Ada programming so I apologize in advance for any errors in my knowledge of Ada. Both C++ and Ada have their strengths and weaknesses, I'm not fond of either as a "favorite" langauge though I have some preference for C++ due primarily to better familiarity. >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. However, C++ doesn't use a class=module approach. You're comment applies more to a language like Eiffel. C++ uses the class to control information hiding, similar to (one function of) Ada's package. >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. No they don't. I suggest you look at the GNU g++ library implementation of complex, which I summarize below. Note that there are NO friend functions. There are differences, reflecting the differences between Ada's and C++'s approaches to types and differences in the approach to the implementation. On the other hand, Ada packages are analagous to providing a "friend" declaration between all types declared in the package. If "friends are so bad, then Complex and Imaginary should be in different packages so they can't get at each other's internals (which is basically what a C++ friend declaration does). NOTE: I've edited the following somewhat to remove inline function implementations and several of the operations. /* Copyright (C) 1988 Free Software Foundation written by Doug Lea (dl@rocky.oswego.edu) This file is part of GNU CC. */ class Complex { protected: // analagous to Ada's private part double re; double im; public: inline double real() const; // get real part of number inline double imag() const; // get imaginary part of number // Create a complex number inline Complex(); inline Complex(const Complex& y); inline Complex(double r, double i=0); // assignment inline Complex& operator = (const Complex& y); // Basic operations (add to number, subtract from number, etc). inline Complex& operator += (const Complex& y); inline Complex& operator += (double y); inline Complex& operator -= (const Complex& y); inline Complex& operator -= (double y); inline Complex& operator *= (const Complex& y); inline Complex& operator *= (double y); Complex& operator /= (const Complex& y); Complex& operator /= (double y); }; // Other operations on Complex. No friend functions needed. // Comparison operations. int operator == (const Complex& x, const Complex& y); int operator == (const Complex& x, double y); int operator != (const Complex& x, const Complex& y); int operator != (const Complex& x, double y); Complex operator - (const Complex& x); // negation Complex conj(const Complex& x); // conjugate // Arithmetic: Complex operator + (const Complex& x, const Complex& y); Complex operator + (const Complex& x, double y); Complex operator + (double x, const Complex& y); Complex operator - (const Complex& x, const Complex& y); Complex operator - (const Complex& x, double y); Complex operator - (double x, const Complex& y); // Similarly for *, /. // More complicated operations: Complex polar(double r, double t = 0.0); Complex cos(const Complex& x); Complex sin(const Complex& x); // (removed abs, norm, arg, sinh, cosh, exp, log, pow (power), sqrt). > 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++. I'm sure a C++ example could be created with classes Real, Imaginary, and Complex. There are also things which a C++ version could do and Ada can't. For instance, I don't think your Ada version as specified above allows assignment between types, in particular, how do I assign an imaginary value to a complex? Complex := Imaginary; -- type violation. Complex := Cmplx(Real, Imaginary); -- defined as Cmplx(Real, Real) Complex := (0, Imaginary); -- private type. I assume I have to get the package implementor to write a new function: function Cmplx(re: Real; Im: Imaginary) return Complex; Or alternately something like: Complex := Cmplx(Re, Real(Im)); -- use explicit conversion. ` -- can I do this to generics? >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. And one could write a very poorly structured Ada implementation which violates package structures. You may have some protection above because the package is generic, I'm not familiar enough with Ada generics. I do agree that it's easier to create poorly packaged code in C++ than in Ada. From that standpoint Ada provides better encapsulation, but it's by no means ideal. There is also a problem discussed extensively in the Ada 9X materials about how to handle mixing operations of types Matrix and Vector, so Ada's encapsulation has it's problems also (this particular problem isn't easy in either class based languages like Eiffel or in C++ either, though solutions can be done in any of these langauges). >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. Regardless of the above, you're right to maintain Ada's encapsulation philosophy. I don't like Ada's approach as much as some others, but there's nothing inherently wrong with it. >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... True, though I'm not sure Ada 9X is advancing the state of the art past other languages (personal opinion). >S. Tucker Taft stt@inmet.com >Ada 9X Mapping/Revision Team >Intermetrics, Inc. >Cambridge, MA 02138