Child packages question

Child packages question

[James Ross]

I have been holding off on asking because I thought I might figure it
out myself.  I only have one Ada 95 book (I guess I oughta  buy more)
and it is not clear on this issue.  As for looking on the net, I have
browsed, but not extensively.  

Is it possible to control accessibility / visibility of packages using
the child mechanism?  

For example; Car and Car.Engine -- I want the user to be able to "use"
Car but not Car.Engine. The user could call Car.Accelerate_Mph, but
only the Car package could call Car.Engine.Pump_More_Gas.

Am I all wet here and that is NOT what child packages is all about?
It appears that Child packages may be just a way of organizing closely
related functionality and expanding the namespace. Thanks for any
insights, advice, flames, etc...
JR

Re: Child packages question

[sk]

Hi,

-----------------------------------------------------
-- file1 : car.ads
package Car is

    procedure Accelerate;

end Car;

-----------------------------------------------------
-- file2 : car.ads
with Car.Engine;

package body Car is 

    procedure Accelerate is
    begin
        Car.Engine.Pump_More_Gas;
    end Accelerate;

end Car;  

-----------------------------------------------------
-- file2 : car-engine.ads
private package Car.Engine is

    procedure Pump_More_Gas;

end Car.Engine;

-----------------------------------------------------
-- file2 : car-engine.adb
package body Car.Engine is

    procedure Pump_More_Gas is
    begin
        null;
    end Pump_More_Gas;

end Car.Engine;

-----------------------------------------------------
-- file2 : Mario_Andretti.adb
with Car;
--with Car.Engine;

procedure Mario_Andretti is

begin
    Car.Accelerate;
    
--    Car.Engine.Accelerate;

end Mario_Andretti;
-----------------------------------------------------

Try uncommenting :
"with Car.Engine" 
"Car.Engine.Accelerate"

Compiler should complain :-)

-- 
-------------------------------------
-- Merge vertically for real address
-------------------------------------
s n p @ t . o
 k i e k c c m
-------------------------------------

RE: Child packages question

[Steven Deller]

Nice example.

The second commented item (that you want to uncomment and see a
complaint) should read:
--    Car.Engine.Pump_More_Gas ;
not 
--    Car.Engine.Accelerate;

Of course a compiler will complain about either, but I believe the
germane complaint (regarding private package) would occur for the first.

Regards,
Steve

> -----Original Message-----
> From: comp.lang.ada-admin@ada.eu.org 
> [mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of sk
> Sent: Monday, April 08, 2002 10:17 PM
> To: comp.lang.ada@ada.eu.org
> Subject: Re: Child packages question
> 
> 
> Hi,
> 
> -----------------------------------------------------
> -- file1 : car.ads
> package Car is
> 
>     procedure Accelerate;
> 
> end Car;
> 
> -----------------------------------------------------
> -- file2 : car.ads
> with Car.Engine;
> 
> package body Car is 
> 
>     procedure Accelerate is
>     begin
>         Car.Engine.Pump_More_Gas;
>     end Accelerate;
> 
> end Car;  
> 
> -----------------------------------------------------
> -- file2 : car-engine.ads
> private package Car.Engine is
> 
>     procedure Pump_More_Gas;
> 
> end Car.Engine;
> 
> -----------------------------------------------------
> -- file2 : car-engine.adb
> package body Car.Engine is
> 
>     procedure Pump_More_Gas is
>     begin
>         null;
>     end Pump_More_Gas;
> 
> end Car.Engine;
> 
> -----------------------------------------------------
> -- file2 : Mario_Andretti.adb
> with Car;
> --with Car.Engine;
> 
> procedure Mario_Andretti is
> 
> begin
>     Car.Accelerate;
>     
> --    Car.Engine.Accelerate;
> 
> end Mario_Andretti;
> -----------------------------------------------------
> 
> Try uncommenting :
> "with Car.Engine" 
> "Car.Engine.Accelerate"
> 
> Compiler should complain :-)
> 
> -- 
> -------------------------------------
> -- Merge vertically for real address
> -------------------------------------
> s n p @ t . o
>  k i e k c c m
> -------------------------------------
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org 
> http://ada.eu.org/mailman/listinfo/comp.lang.ad> a
> 

Re: Child packages question

[Pat Rogers]

"James Ross" <rem.jr@rem.webross.com> wrote in message
news:fug4bukpc28gaqh1sci8m9ql2k1oa54ms5@4ax.com...
> I have been holding off on asking because I thought I might figure it
> out myself.  I only have one Ada 95 book (I guess I oughta  buy more)
> and it is not clear on this issue.  As for looking on the net, I have
> browsed, but not extensively.
>
> Is it possible to control accessibility / visibility of packages using
> the child mechanism?
>
> For example; Car and Car.Engine -- I want the user to be able to "use"
> Car but not Car.Engine. The user could call Car.Accelerate_Mph, but
> only the Car package could call Car.Engine.Pump_More_Gas.
>
> Am I all wet here and that is NOT what child packages is all about?
> It appears that Child packages may be just a way of organizing closely
> related functionality and expanding the namespace. Thanks for any
> insights, advice, flames, etc...


You should definitely have a look at the Rationale, plus it's free so no need to
go buy another Ada book, although I don't think one can have too many!  :-)

Re: Child packages question

[sk]

Hi,

>complaint) should read:
>--    Car.Engine.Pump_More_Gas ;
>not 
>--    Car.Engine.Accelerate;

Oops, I saw the compiler complain as I expected,
didn't look closely enough at what it was complaining
about :-)



--
------------------------------------
-- Merge vertically for real address
-------------------------------------
s n p @ t . o
 k i e k c c m
-------------------------------------

Re: Child packages question

[Randy Brukardt]

Look at private packages (they're really only useful for children). See
10.1.1 in the ARM.

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.

            Randy.

James Ross wrote in message ...
>I have been holding off on asking because I thought I might figure it
>out myself.  I only have one Ada 95 book (I guess I oughta  buy more)
>and it is not clear on this issue.  As for looking on the net, I have
>browsed, but not extensively.
>
>Is it possible to control accessibility / visibility of packages using
>the child mechanism?
>
>For example; Car and Car.Engine -- I want the user to be able to "use"
>Car but not Car.Engine. The user could call Car.Accelerate_Mph, but
>only the Car package could call Car.Engine.Pump_More_Gas.
>
>Am I all wet here and that is NOT what child packages is all about?
>It appears that Child packages may be just a way of organizing closely
>related functionality and expanding the namespace. Thanks for any
>insights, advice, flames, etc...
>JR
>

Re: Child packages question

[James Ross]

sk wrote:

>Hi,

Thanks sk!  and others.  I ditto the nice example comment.  That is
precisely the answer.  When I first looked at it, I thought hey wait a
minute, he's done nothing special there... Then I noticed the missing
piece of the puzzle:   starting the child package with "private
package".  I was certain there was a way, and was almost certain it
was private ... something, but I thought some declaration either in
the spec or body of Car... 

Oh yeah, I like Ada a bit more now.

If I am not mistaken, it appears that Ada 95 Problem Solving and
Program Design (2and Edition) never mentions it. 
JR
  
>-----------------------------------------------------
>-- file1 : car.ads
>package Car is
>
>    procedure Accelerate;
>
>end Car;
>
>-----------------------------------------------------
>-- file2 : car.ads
>with Car.Engine;
>
>package body Car is 
>
>    procedure Accelerate is
>    begin
>        Car.Engine.Pump_More_Gas;
>    end Accelerate;
>
>end Car;  
>
>-----------------------------------------------------
>-- file2 : car-engine.ads
>private package Car.Engine is
>
>    procedure Pump_More_Gas;
>
>end Car.Engine;
>
>-----------------------------------------------------
>-- file2 : car-engine.adb
>package body Car.Engine is
>
>    procedure Pump_More_Gas is
>    begin
>        null;
>    end Pump_More_Gas;
>
>end Car.Engine;
>
>-----------------------------------------------------
>-- file2 : Mario_Andretti.adb
>with Car;
>--with Car.Engine;
>
>procedure Mario_Andretti is
>
>begin
>    Car.Accelerate;
>    
>--    Car.Engine.Accelerate;
>
>end Mario_Andretti;
>-----------------------------------------------------
>
>Try uncommenting :
>"with Car.Engine" 
>"Car.Engine.Accelerate"
>
>Compiler should complain :-)

Re: Child packages question

[sk]

Hi,

My personal recomendations, 

Barnes : Programming in Ada'95
Cohen : Ada as a Second Language

Barnes provides tons of trivial examples like 
the one I gave. Cohen provides a more in depth
coverage of issues.

If you manage to pick them up, make doubly
sure that you have the Ada _*95*_ versions.

I found that relying on my original Barnes and 
Cohen written for Ada 83, and hoping that I would
easily notice the differences through the LRM and 
AARM, severely retarded my transition from '83 to '95.

-- 
-------------------------------------
-- Merge vertically for real address
-------------------------------------
s n p @ t . o
 k i e k c c m
-------------------------------------

Re: Child packages question

[Ingo Marks]

James Ross wrote:

> Oh yeah, I like Ada a bit more now.

I have had the same experience. At first, Ada was pretty hard to learn for 
me, but now ... The more I write in Ada, the more I like this language :-)

Ingo

Re: Child packages question

[tmoran]

>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
commonly a child package extends somehow its parent.  For instance,
claw.sockets has a bunch of stuff, but claw.sockets.non-blocking has
extensions for those times you want your sockets to be non-blocking.  It
can't be claw.sockets_non_blocking, "with"ing claw.sockets, because it
needs access to some things that the parent claw.sockets does not make
public.
  So usually children see parents, in more detail than the general public,
but parents don't see children.  The phraseology of parent/child/private
parts etc just doesn't work nicely, at least if you are thinking of
humans.  Perhaps there's a nicer animal model.
  If you want Car to see Car.Engine, you probably want Car.Engine to be
a package *inside* of Car, not a child of Car.  Then the two packages
can see (selectively) parts of each other.

Re: Child packages question

[Ted Dennison]

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).


-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Child packages question

[Randy Brukardt]

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.