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,b1f194b75ae020e4,start
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 1995-03-24 13:07:23 PST
Path: 
 nntp.gmd.de!news.rwth-aachen.de!news.rhrz.uni-bonn.de!news.uni-stuttgart.de!alpha1.csv.ica.uni-stuttgart.de!ucaa2385
From: ucaa2385@alpha1.csv.ica.uni-stuttgart.de (Peter Hermann)
Newsgroups: comp.lang.ada
Subject: children
Date: 24 Mar 1995 19:21:55 GMT
Organization: Comp.Center (RUS), U of Stuttgart, FRG
Message-ID: <3kv64j$1fhh@info4.rus.uni-stuttgart.de>
NNTP-Posting-Host: alpha1.csv.ica.uni-stuttgart.de
X-Newsreader: TIN [version 1.2 PL2]
Date: 1995-03-24T19:21:55+00:00
List-Id: <comp.lang.ada>


for the sake of gaining other opinions I am posting (with agreement)
an off-line discussion between eachus@spectre.mitre.org and me(ph).

topic: child packages talk about parent's secrets:
       break of information hiding.

ph:>   > I would not recommend that whole direction because
   >   > one of the strengths of the child feature is exactly the fact,
   >   > that the parent need not be touched further on.
             ^ the code of

ea:>    I work in a field where this alternative is not acceptable.  A
   > modification which affects the value of variables in a package must be
   > reflected in the documentation., etc.
   > 
   >    The benefit of this proposal is that, if the pragma is never used,
   > the user is never bothered.  In the sort of project that concerns me,
   > just before FQT (Formal Qualification Test) the programmers would run
   > a tool to put in the pragmas, and any further modification of the
   > structure would be immediately obvious.  So it would be a big help
   > during maintenance, and no hindrance during development.  Seems
   > win-win to me.

ph:Your argument qualifies well to be spread to all in c.l.a. .
   We are all in search of the best possible solution for Ada0X
   and I think there should be further discussion on those 
   topics. Maybe we are both right. Or I am wrong....   , but:
   Some new ideas for this one topic should be found.
   For quality assurance you are extremely right above.

   What attracts me, are the advances in SE-principles, OO-principles,
   e.g. that a piece of software remains unchanged.

   For our special problem it is conceivable that
   a compiler is able to detect "nasty children"
   in the same way as "non-portable constructs".
   This would be an acceptable way for me, too.

ea:
   Good point.  If the compiler is detecting illegitimate children, it
could also warn of any violation of good OO and SE principles, by that
child.  Let's see...I'd want a warning for any direct assignments to
variables in the body or the private part, and any overriding of
dispatching operations for types declared in the parent.  Anything
else?

   Both of those checks seem very easy to add to a compiler, and both
are in the category of practices which are useful, but (potentially)
dangerous.  However, I think there are a lot of other things that I
want compiler vendors to worry about first.  My only reason for
bringing the pragma up was that users can start adding it as
documentation with no compiler support, and/or support by other tools,
but we need a consensus on the spelling.