Re: Ada OO Mechanism

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

In article <t7k8tvqyjr.fsf@calumny.jyacc.com>,
	Hyman Rosen <hymie@prolifics.com> wrote:

>Richard D Riehle <laoXhai@ix.netcom.com> 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