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.9 required=5.0 tests=BAYES_00 autolearn=ham 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/27 Message-ID: <7ii2bq$5nk@sjx-ixn6.ix.netcom.com> X-Deja-AN: 482521877 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> <7ihf6i$4hv@dfw-ixnews10.ix.netcom.com> Organization: Netcom X-NETCOM-Date: Wed May 26 5:07:22 PM PDT 1999 Newsgroups: comp.lang.ada Date: 1999-05-26T17:07:22-07:00 List-Id: In article , Hyman Rosen wrote: >Richard D Riehle writes: >> 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; > >Overloading by return type and having that control dispatching looks >like a good example of something that you can't do in C++. So is the >concept of class-wide type itself - there's no equivalent in C++ for >Ada's T'Class type. From a little fooling around with your code above >and gnat, and the Rationale, it looks like the compiler has to examine >the code that attempts to initialize a T'Class variable and allocate >the maximum space for it that that code would require. C++ doesn't do >any of that - C++ coders would be using dynamic allocation and pointers >or references to pass around arbitray subclasses. Interesting. In actual Ada OOP, especially when using Stream_IO for storage of heterogenuous types, it is typical to use access (pointer) types also. One reason I used the illustration with access parameters is to accomodate that practice. Now for the bad news. Ada access parameters allow the programmer to violate the encapsulation too. Although the access parameter itself is regarded as an in parameter in Ada, a programmer may dereference data being referenced, if there is visibility to the data. In this regard, I think C++ is a little stronger because of the option of const functions and const parameters. My preference for a future addition to the Ada standard would be some kind of constant function such as, constant function F (A : access some-type) return T; or, closer to C++, function F (A : constant access some-time) return T; which would disallow any monkey business with the function. In fact, this would correspond to the notion of a query with no possible ] side-effects (much like the protected type function) and satisfy Bertrand Meyer's insistence that queries should only query and modifiers should only modify. This is one feature of Ada, for object-oriented programming where I think C++ is a little stronger. >It is a fallacy that friend functions break encapsulation. Friendship >is granted explicitly by a class. These friends are part of the >encapsulation. Friends are "part of the encapsulation", but also seem, to me, to be an awkward feature included to compensate for problems associated with the class <=> type <=> module model. Without this kind of model, the notion of friends would be unnecessary. >Mutable has nothing at all to do with this - mutable >members of an object may be modified even when the object is declared >to be 'const'. The intent is to provide a difference between logical >constness and physical constness. For example, one would expect that >the characters of a const string would never change, but there could >be an internal reference count that needs adjustment. That count would >be declared mutable. I understand that mutable is a feature for reversing const'ness. We have in Ada the notion of a general access constant that satisfies the situation you mention, if I understand your explanation. It just seems, once again, that this is an add-on to compensate for a language weakness rather than a coherent part of the overall design. >For completeness sake, class member templates *can* be used to break >encapsulation. The C++ philosophy is to protect encapsulation against >Murphy but not Machiavelli. This is a key difference between Ada and C++. Ada, the language, is designed to maximize the number of errors that can be caught during compilation, as early in the process as possible. This is one reason for requiring that ancestral library units be correctly compiled before one can compile a dependent unit. It is one reason why access types (pointers) are so strictly controlled, and it is also why we have, in Ada, a strong separation between the notions of scope and visibility. The philosophies of the two language designs are different. As you noted earlier regarding templates, if it compiles in C++, it is OK, but there may be problems lurking in the code. In Ada, the goal is to ensure that a compiled template (generic) correspond completely to the associated signatures of generic formal parameters. This is one reason Ada generic formal package parameters seem, at first, to be more bizzare than those in C++. We are trying to put both Murphy and Machiavelli out of business. Too ambitious. Probably. But that is the goal, and one reason why Ada is designed as it is. I have enjoyed our little discussions. Thanks for your participation. It is now essential I return to doing some real programming even though this has been fun. Thanks, Hyman, Richard Riehle richard@adaworks.com http://www.adaworks.com