Re: Some questions on a library design

[Brian Rogoff <bpr@shellx.best.com>]

On Tue, 17 Jun 1997, Robert A Duff wrote:
> Brian Rogoff  <bpr@shellx.best.com> wrote:
> >Hi,
> >	In the process of writing a collection library for Ada I have 
> >encountered a few stumbling blocks that I hope can be removed. The library 
> >is rather like the C++ STL, and so I avoid dynamic dispatching 
> >*completely*. I have also avoided tagged types although that is not
> >strictly necessary.
> 
> If I were doing it, I think I would use tagged types and inheritence.
> Let the client decide whether dispatching calls are too inefficient.
> One nice thing about Ada, is that you can choose to use dispatching or
> not, on a call-by-call basis.

There is nothing stopping the client from storing tagged types in the 
AGL collections, and dispatching on them in the client code. But why 
should I have dispatching in the library when all of the container types 
are known statically? 

In any case, I am deliberately copying the STL, in which dynamic dispatch, 
benefits and all, is avoided. You may prefer the Booch components to the 
AGL, and there is room for both (and more!).
 
> >...However, I am 
> >having a bit of trouble figuring out how to do this; so far I just declare
> >the Red_Black_Trees package in the public part of Sets' spec, and do the
> >same with Red_Black_Trees.Iterators in Sets.Iterators, like so:
> 
> Would it help to pass in a generic formal package?

I'm not sure I understand your suggestion. Do you mean pass in a generic
formal package (which would get Red_Black_Trees or Splay_Trees) to the
Sets package, and then do a bunch of subtypes and renamings to get the Sets 
interface? Thats a possibility I have considered, and one that the authors 
of the RPI Ada STL implemented for deriving Queues from other containers 
(they call it "Adaptors") but I am not convinced that this is best, mainly 
because I think that in order to use the generic formal package approach,
you'd want to bundle it up the actual representation with a signature
package, something like 

package RB_Trees is new AGL.Red_Black_Trees (...);
package Set_Reps is new AGL.Set_Signatures( Set_Type => RB_Trees.Tree_Type, 
                                        Element_Type => RB_Trees.Element_Type,
                                        ... etc... );
package My_Sets is new AGL.Sets ( Set_Reps );

leads to too many unhelpful instantiations by the client. 

If that wasn't what you were suggesting, my apologies, and please describe 
what you mean.

Ideally (IMO), the client should be able to create a new set package by
going 

package My_Sets is new AGL.Sets ( Element_Type => Integer, "<" => "<" ); 

and all of the iterators for the set with

package My_Sets_Iters is new My_Sets.Iterators;

without even knowing about red-black trees, splay trees, hash tables, or 
whatever the implementation is, unless of course they want to change it.

What I have been wishing for is a way to define a new generic package in 
terms of an existing one by instantiating some of its parameters. Renaming 
is not quite right because I want the "renamed" package (say AGL.Sets) to
be generic, and I may want to fill in some of the parameters of the generic 
package being renamed (AGL.Red_Black_Trees has a Boolean "Insert_Always" 
flag whose value determines whether the package describes a set or a
multiset).

A while ago, Norman Cohen suggested "package parts" as a solution to the 
infamous "withing problem". There have been quite a few times while I've 
been crafting at this library that I also wished for the ability to
interleave specs and private parts, so I certainly appreciate that
suggestion a lot more now, outside of the context of package spanning
mutually recursive specs!

-- Brian