Re: how to import a package

["Stuart" <stuart@0.0>]

"markww" <markww@gmail.com> wrote in message 
news:1165893584.829025.235440@l12g2000cwl.googlegroups.com...
> I'm wondering still if it's possible to have a data member in the
> package definition that serve as my start and end nodes. In C++ I'd do
> something like:

<snip C>

> am I allowed to do the same in my package definition? Then things would
> be a lot neater.

As Jeff Carter explained - yes you can.  The approach you currently have is 
often referred to as an Abstract Data Type (ADT), whereas what you are 
considering is an Abstract State Machine (ASM).  The topic is worth 
researching.  It is a very important program design consideration as to 
whether to make something an ADT or an ASM as it controls the location of 
state and the nature of the interface.  This is a lesson that is emphasized 
in the design of SPARK (see www.sparkada.com)  programs.

Given an ADT it is quite straightforward to create an ASM; you simply create 
a package that contains the state variable and replicates each of the ADT 
operations, omitting the Object parameter from their own parameter list and 
using the state variable when calling the ADT operation to provide the 
functionality.

   package ADT is
       type T is private;
       procedure Add(Item : in       integer;
                               To    : in out T);
       function Initialize(Initial : in integer) return T;
  private
     type T is integer; -- Just a demo!
  end ADT;

   with ADT;
   package ASM is
      procedure Add(Item : in integer);
   private
      State : ADT.T := ADT.Initialize(0);
   end ASM;

   package body ASM is
      procedure Add(Item : in integer) is
      begin
         ADT.Add(Item => Item,
                          To   => State);
     end Add;
   end ASM;

> Right now I have the start and end pointers as variables external to
> the package, so everytime I call AddNode() etc I have to pass
> them through which is pretty sloppy. It looks like:

Why do you have them as separate variables?  You could create a type (call 
it, say, List) that has both these components.  Having 'cracked' generics 
you might want to go back and think very carefully about what the 'visible' 
parts of your ADT/ASM are, and what are 'private' details.  Generally the 
more you make private the less chance there is of things getting messed up, 
and the easier it is to make changes to the underlying type to 
develop/extend/improve your design.

Jeff's suggestion of looking at the design of  packages like Containers is a 
good one.

Regards
-- 
Stuart