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-Thread: 103376,b8b8a54001adc4d2 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news.glorb.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Possible Ada deficiency? Date: Sun, 2 Jan 2005 11:26:35 +0100 Organization: cbb software GmbH Message-ID: <1ddc37oix9i4f$.1vg08vxihbwtw$.dlg@40tude.net> References: <1104516913.718856.94090@z14g2000cwz.googlegroups.com> <1104622090.271236.286730@c13g2000cwb.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: individual.net xv4QCFKcYuO66hUjAAd7xAgPZh7LE6GF7AoVcWW60u+e+I73s= User-Agent: 40tude_Dialog/2.0.12.1 Xref: g2news1.google.com comp.lang.ada:7386 Date: 2005-01-02T11:26:35+01:00 List-Id: 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