Re: advice on package design

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 7 Mar 2005 08:23:58 -0800, spambox@volja.net wrote:

> Hello,
> I've written a package for linked list operations for my personal use.
> After a while I figured I'd write another package for some string
> operations that I use frequently. On their own, they both work well.
> Now comes the problem.
> My string library uses my linked list library, which must be
> instantiated -- the structure of a node must be supplied. After that,
> the string library can use procedures from the linked list library. But
> what about the end user? The linked list library defines a type, say
> linked_list, and the string library instantiates it something like:
> 
> type word is record ...
> package string_ll is new linkedlists(word);
> use string_ll;
> 
> Ultimatelly, if some function from my strings package returns a
> linked_list (as defined in the linked list package), it will be of the
> type string_ll.linked_list, if we follow the above example. How could
> it be available for further processing with routines from the linked
> list package?
> 
> I could "use string_ll" (exactly as in the package) in my end program,
> however that's probably a poor design, since the user need not know how
> something was instantiated in another package.

The public part of the package is its interface. If you instantiate
something there, then it is OK for all to use it.

> If, on the other hand, I make another instance of linkedlist, I must
> supply the same argument the string package does ("word" in the above
> example), but then the resulting linked_list type would be
> some_new_name.linked_list, which is not compatible with what the string
> package uses (string_ll.linked_list in the example).

Yes. Ada has named type equivalence.

> What is the correct way of dealing with such problems?

There are many different ways to deal with that. If you have

1. 

package Foo is
   type Word is ...
   package Baz is new Bar (Word,...);
   ...
end Foo;

then of course you can "use" Baz referencing it as Foo.Baz everywhere Foo
is "with"-ed. You can even rename it:

with Foo;
package Baz renames Foo.Baz;

2. You can instantiate your Baz outside Foo but with the things defined in
the public part of Foo:

with Foo;  use Foo;
package Baz is new Bar (Word,...);

Note that the body of Foo may still use Baz:

with Baz;
package body Foo is ... end Foo;

Though beware that there must exits an elaboration order of the
specifications and bodies Foo and Bar.

2.a. If Bar needs privates of Foo, the you can make Bar a generic child of
Foo.

3. You can rename parts of contents of Baz in Foo:

package Foo is
   type Word is ...
   package Baz is new Bar (Word, ...);

   subtype Linked_List is Baz.Linked_List; -- "renaming" of a type
   procedure Insert (...) renames Baz.Insert; -- renaming of a procedure
   ...
end Foo;

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de