Re: Possible Ada deficiency?

["Randy Brukardt" <randy@rrsoftware.com>]

<danmcleran@hotmail.com> wrote in message
news:1104595073.731663.180100@c13g2000cwb.googlegroups.com...
> Yes, but it seems like such an obvious place where bad things could
> happen. It seems like only goodness can be bought by having the ability
> to hide a type's impelmentation from child packages. I don't see any
> downside to providing this ability. That way, one could force a child
> package to use the interface provided by the public area of its parent
> and prevent the child from manipulating the internal representation of
> a type.

The purpose of a child package is to extend its parent, often in ways not
forseen by the parent's author. You're trying to prevent that purpose. If
you don't want access to the private information, then don't write children.
You have to at some point trust programmers to do something sensible; it's
not the least bit hard to use 'Address or Unchecked_Conversion to access the
private information of a package, no matter where you hide it.

Since children are obvious syntactically, it is easy to determine if a
particular program has any. If your project is creating child packages
willy-nilly, it has project management problems far beyond anything a mere
programming language can help with.

For public packages (like Claw), it's just as easy. Write a child, you're on
your own -- because the only reason to write a child is to get access to
implementation details. Once you do that, we aren't likely to support the
result.

Repeat after me: it's not the least bit hard in any programming language to
write bad code. Ada can only do so much; you have to have coding rules and
the project management to make them stick to get the whole job done.
Otherwise, you can write a morass of child packages, use clauses, address
clauses to make overlays, and so on to rival any messy C code. (Indeed,
these sorts of things are used to translate C to Ada automatically - garbage
in, worse garbage out!).

                               Randy.