Re: An observation of Ada (may offend)

["S. Tucker Taft" <stt@inmet.com>]

ncohen@watson.ibm.com (Norman H. Cohen) wrote:
>
> In article <3kbkm1$41o@miranda.gmrc.gecm.com>, bill@valiant.gmrc.gecm.com
> (R.A.L Williams) writes: 
>... 
> |> h. And a special one for Ada95: poor encapsulation of objects. I can
> |> define a 'member function' for a class by including the class in the
> |> parameter list. Unlike C++ or Eiffel, I can do this *anywhere* in my code,
> |> even a nested function hidden somewhere seemingly 'irrelevant'. Whereas
> |> other features of Ada go out of their way to force the programmer to
> |> follow 'good practice' (sometimes a matter of opinion), this seems
> |> very lax.
> ...
> 
> If there is a weakness in Ada encapsulation, it has nothing to do with
> parameter lists, but with the definition of "logically within the
> defining unit".  Anyone can write a child package that is "logically
> within the defining unit".  (Do-While Jones once called this the "Howard
> Hughes effect": strangers claiming to be your heirs.)  Child units enjoy
> access analogous to that permitted for C++ protected members in a
> subclass of a definining class.  Thus the strongest degree of hiding that
> Ada can provide is that of C++ "protected", not C++ "private".

By putting a declaration in a nested package private part, or in
the package body, you achieve hiding as effective as C++ "private."  
When introducing Ada 95 to C++ programmers, I generally explain that
Ada has three levels of visibility control, analagous to the three in
C++ -- the visible part of a package (visible to all), the private
part of the package (visible to children), and the package body
(visible to the package body itself only).  Most C++ programmers
are a bit jealous of the ability to define in Ada 95 additional
local subprograms in a package body without having to disturb the
spec.  In C++, you have to edit the class spec to add private
member functions (or play games with "friends").
 
> Norman H. Cohen    ncohen@watson.ibm.com

-Tucker Taft  stt@inmet.com
Intermetrics, Inc.