* Re: Encapsulation in Ada vs. C++ (Was Re: Ichibah [sic] ...) @ 1993-03-16 22:37 John Goodsen 0 siblings, 0 replies; 5+ messages in thread From: John Goodsen @ 1993-03-16 22:37 UTC (permalink / raw) magnus@lglsun.epfl.ch (Magnus Kempe) writes: > >If your class Foo grants "friendship" to a function/class Bar, _anyone_ >can write such a function/class and, having granted itself "friendliness", >will have access to the internals of Foo. > Oh my! And shame, shame, shame on you for even thinking imitating my "BAR". This argument is remeniscent of the facist arguments which have the common theme of "you might use it wrong, therefore I want to keep you from using it at all". BTW, you won't get too far in the link stage with both "BAR"s in the system (multiply defined identifiers and such..) > >To repeat: contrary to Ada, C++ does not provide a safe means to create >subprograms acting on parameters of two or more types (classes). In >C++, either you write an unsafe class because the language lacks the >concept of a module, or you twist around with .h files and say good-bye >to limited, separate recompilations. > "UNSAFE CLASS" ??? Huh? Come now! "friendship" is not necessarily unsafe. Only if you use it wrong. True, Ada packaging and "classtypes" (I refuse to use tagged type syntax anymore ;-) overcome this *perceived* defect in C++, but to *twist* the truth in suggesting that you lose separate recompilations is not responsible. In fact to the contrary, the *friend* concept allows for separate recompilation of these related classes and functions. Ada packages *REQUIRE* recompilation of all related "classtypes" (there it is again, isn't it a pretty syntax ;-), since they're in the same package. -- John Goodsen Software Process & Environments EVB Software Engineering jgg@evb.com ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Ichibah flames, and flames out over, Ada 9X @ 1993-03-07 19:15 John Goodsen 1993-03-08 15:36 ` Tucker Taft 0 siblings, 1 reply; 5+ messages in thread From: John Goodsen @ 1993-03-07 19:15 UTC (permalink / raw) >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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Ichibah flames, and flames out over, Ada 9X 1993-03-07 19:15 Ichibah flames, and flames out over, Ada 9X John Goodsen @ 1993-03-08 15:36 ` Tucker Taft 1993-03-09 18:12 ` Tom Wicklund 0 siblings, 1 reply; 5+ messages in thread From: Tucker Taft @ 1993-03-08 15:36 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Ichibah flames, and flames out over, Ada 9X 1993-03-08 15:36 ` Tucker Taft @ 1993-03-09 18:12 ` Tom Wicklund 1993-03-11 8:04 ` Encapsulation in Ada vs. C++ (Was Re: Ichibah [sic] ...) Magnus Kempe 0 siblings, 1 reply; 5+ messages in thread From: Tom Wicklund @ 1993-03-09 18:12 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Encapsulation in Ada vs. C++ (Was Re: Ichibah [sic] ...) 1993-03-09 18:12 ` Tom Wicklund @ 1993-03-11 8:04 ` Magnus Kempe 1993-03-16 6:34 ` Dag Bruck 0 siblings, 1 reply; 5+ messages in thread From: Magnus Kempe @ 1993-03-11 8:04 UTC (permalink / raw) Taft showed how a package allows one to encapsulate _several_ types and their operations, providing such natural and efficient notations as "A := 2 + 3 * i;" ("A" is of type Complex and "i" is of type Imaginary; "+" and "*" are the operations). The crux of Taft's example is that Ada allows one to declare _several_ types _together_ and thus be able to easily provide an efficient subprogram operating on _several_ objects of _different_ types. All this can be achieved within a package with the safety provided by private types (since no one else is allowed to proclaim itself so "friendly" as to see the private parts of your package...). To achieve this, operators would have to be "friends" in C++, because of its equation "module = class"; however, the problem with such an approach is that _anyone_ can then claim to be a "friend", and therefore _anyone_ can break the abstraction of the class. C++ "friends" break the encapsulation and its equation becomes an approximation: "a class with friends is almost a module". wicklund@intellistor.com (Tom Wicklund) answered Taft with an irrelevant example: : : I suggest you look at the GNU g++ library implementation of complex, : which I summarize below. Note that there are NO friend functions. Of course, there are no friends in your C++ code (not repeated here), since the C++ class you included does _not_ propose _two_ types and operations working on objects of both types. (BTW, I'd rather see a discussion of principles with approriate examples; pouring hundreds of lines of C++ code in comp.lang.ada is uninteresting. Thank you.) To summarize, the crucial concepts involved are the following: we want a natural notation to declare several types and associated, efficient subprograms operating on several parameters of different types, and we want all this while preserving the abstraction in its encapsulation and type safety. Ada satisfies such software engineering requirements, and Ada 9X will soon provide still more programming power to satisfy still more software engineering requirements. (How great!) -- Magnus Kempe "No nation was ever drunk when wine was cheap." magnus@lglsun.epfl.ch -- Thomas Jefferson ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Encapsulation in Ada vs. C++ (Was Re: Ichibah [sic] ...) 1993-03-11 8:04 ` Encapsulation in Ada vs. C++ (Was Re: Ichibah [sic] ...) Magnus Kempe @ 1993-03-16 6:34 ` Dag Bruck 1993-03-16 7:51 ` Magnus Kempe 0 siblings, 1 reply; 5+ messages in thread From: Dag Bruck @ 1993-03-16 6:34 UTC (permalink / raw) In <comp.lang.ada> magnus@lglsun.epfl.ch (Magnus Kempe) writes: > >To achieve this, operators would have to be "friends" in C++, >because of its equation "module = class"; however, the problem >with such an approach is that _anyone_ can then claim to be a >"friend", and therefore _anyone_ can break the abstraction of >the class. This is incorrect. A class grants friendship to other functions or classes, which means that the author of a class controls who gets access to the private members of the class. You cannot grant yourself access to any random class. -- Dag Bruck ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Encapsulation in Ada vs. C++ (Was Re: Ichibah [sic] ...) 1993-03-16 6:34 ` Dag Bruck @ 1993-03-16 7:51 ` Magnus Kempe 1993-03-16 9:51 ` Dag Bruck 0 siblings, 1 reply; 5+ messages in thread From: Magnus Kempe @ 1993-03-16 7:51 UTC (permalink / raw) dag@control.lth.se (Dag Bruck) writes: : A [C++] class grants friendship to other functions or classes, which means : that the author of a class controls who gets access to the private : members of the class. You cannot grant yourself access to any random : class. If your class Foo grants "friendship" to a function/class Bar, _anyone_ can write such a function/class and, having granted itself "friendliness", will have access to the internals of Foo. To repeat: contrary to Ada, C++ does not provide a safe means to create subprograms acting on parameters of two or more types (classes). In C++, either you write an unsafe class because the language lacks the concept of a module, or you twist around with .h files and say good-bye to limited, separate recompilations. -- Magnus Kempe "No nation was ever drunk when wine was cheap." magnus@lglsun.epfl.ch -- Thomas Jefferson ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Encapsulation in Ada vs. C++ (Was Re: Ichibah [sic] ...) 1993-03-16 7:51 ` Magnus Kempe @ 1993-03-16 9:51 ` Dag Bruck 0 siblings, 0 replies; 5+ messages in thread From: Dag Bruck @ 1993-03-16 9:51 UTC (permalink / raw) In <comp.lang.ada> magnus@lglsun.epfl.ch (Magnus Kempe) writes: >dag@control.lth.se (Dag Bruck) writes: >: A [C++] class grants friendship to other functions or classes, which means >: that the author of a class controls who gets access to the private >: members of the class. You cannot grant yourself access to any random >: class. > >If your class Foo grants "friendship" to a function/class Bar, _anyone_ >can write such a function/class and, having granted itself "friendliness", >will have access to the internals of Foo. If we assume that the author of a class also writes the classes/functions he/she grants friendship, the "one definition rule" prohibits you from writing a second function or class with the same name. The alternative, that the author grants friendship without actually writing the friend classes/functions, seems highly unlikely. If you manipulate library files, for example, replace standard functions with functions you have written yourself, then you can of course get access to anything. You may also patch the symboltable or the objectcode itself. However, I doubt that Ada is safer in this respect. There is a much simpler way to break encapsulation (and I'm sure Magnus Kempe wants to hear it): write a your own class with the same contents and copy the bits from the protected object to a look-alike object with standard C function "memcpy". I doubt that "unsafe" features of this nature is of any real interest. Can anyone give a plausible example? -- Dag ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~1993-03-16 22:37 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1993-03-16 22:37 Encapsulation in Ada vs. C++ (Was Re: Ichibah [sic] ...) John Goodsen -- strict thread matches above, loose matches on Subject: below -- 1993-03-07 19:15 Ichibah flames, and flames out over, Ada 9X John Goodsen 1993-03-08 15:36 ` Tucker Taft 1993-03-09 18:12 ` Tom Wicklund 1993-03-11 8:04 ` Encapsulation in Ada vs. C++ (Was Re: Ichibah [sic] ...) Magnus Kempe 1993-03-16 6:34 ` Dag Bruck 1993-03-16 7:51 ` Magnus Kempe 1993-03-16 9:51 ` Dag Bruck
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox