Re: Child packages question

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

Ted Dennison wrote in message
<4519e058.0204090711.1c3f4248@posting.google.com>...
>tmoran@acm.org wrote in message
news:<QCxs8.1713$UJ7.829234396@newssvr14.news.prodigy.com>...
>> >We put all of the bindings in Claw into private packages
>> >(Claw.Low_Level.Windows, Claw.Low_Level.GDI, etc.). Only Claw can
with
>> >those packages; users of Claw can't access them.
>>   But parent's normally don't call children.  In the Claw case,
Claw.child
>> may call claw.low_level.xxx but that's calling a cousin.  I'd say the
use
>> of child packages for private packages is a less common technique.
More
>
>I use it all the time. Its very nice to be able to split out complex
>functionality into a private hierarchy of packages. Its only natural
>to make them child packages of the public (client interface) package,
>as they logically belong to it.
>
>There's no problem with doing this, as long as its only the *body*
>that needs to with the child (and no generics are involved).

Tom may be confused by the fact that Claw has a style rule which
prevents a parent from withing a child. This is done so that Claw can be
written to elaborate before any possible use. (That's done with careful
use of Elaborate_Body and Elaborate_All, but the mechanism can't be used
on your own children). That rule exists mainly to avoid support calls,
given that it is not usual to declare a Claw object in a library level
package; without the elaboration rules, users would have to remember to
use an Elaborate_All pragma on any Claw unit used to declare such an
object -- otherwise, the call to Initialize could raise Program_Error.

But of course a Claw style rule has nothing to do with a language rule.

                        Randy.