comp.lang.ada
 help / color / mirror / Atom feed
From: ucaa2385@alpha1.csv.ica.uni-stuttgart.de (Peter Hermann)
Subject: children
Date: 24 Mar 1995 19:21:55 GMT
Date: 1995-03-24T19:21:55+00:00	[thread overview]
Message-ID: <3kv64j$1fhh@info4.rus.uni-stuttgart.de> (raw)


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.



             reply	other threads:[~1995-03-24 19:21 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1995-03-24 19:21 Peter Hermann [this message]
1995-03-26 11:56 ` children Robert Dewar
1995-03-28 15:44   ` children Norman H. Cohen
1995-03-30  2:15   ` children Keith Thompson
1995-03-30  0:00     ` children Robb Nebbe
1995-03-27  0:00 ` children Norman H. Cohen
1995-03-30  0:00   ` children Robert I. Eachus
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox