Re: Possible Ada deficiency?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 1 Jan 2005 15:28:10 -0800, danmcleran@hotmail.com wrote:

> Here's a different way to illustrate this problem. If I want to extend
> a type, I can do this with a non-child package. But, if I make the
> package containing the extended type a child package, I then have
> access to all of the private area as well. So, one can extend a type
> with or without access to the private area, depending on whether one
> makes the packages containing the derived type a child package or not.

Yes, this is exactly the idea of child packages. The effect of getting nice
package names A.B.C is a side one. They are not intended for that. You
should use child packages when the implementation cannot be completed by
the parent package, e.g. when a type is abstract or just a root of some
deep hierarchy. Separate bodies could not serve this purpose because they
have to be mentioned in the "parent". Note also that children do not break
hiding. You cannot refer any private thing of the parent in the public part
of a child. But the private child's part naturally extends the private part
of the parent.

You can consider the issue for the point view of how packages are coupled.
Unrelated packages are coupled through with'es of their public parts. So if
B with'es A then the private part of A can be changed without any revision
of B. This is the *actual* reason why something need to be hidden. But
coupling between child and parent is tighter. For A.B the rule above does
not hold. If you change the parent you have to inspect all children. Should
you add "very private" clause (*) or sealed types (**) or whatsoever, that
will not change the situation. So it is simper just not to abuse children
and to use separate bodies instead. The design rule of thumb is: "child is
worse than unrelated". Again, observe that Ada's encapsulation is built on
packages, so child vs. not is a coupling and visibility issue.

> In my example, notice that the derived type in the child package can
> change the private area, whereas the derived type in the non-child
> package cannot.

Yes, it must be so.

-----
* as C++ example shows, people get lost in that complex
public/protected/private issue. Decision protected vs. private in 50% falls
wrong. One could toss a coin instead. What is worse that people get
frustrated and start to make everything public.

** sealed types seem to be even worse than private. 

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de