From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,80a67c84f8039eab X-Google-Attributes: gid103376,public From: Brian Rogoff Subject: Re: Some questions on a library design Date: 1997/06/17 Message-ID: #1/1 X-Deja-AN: 249182091 References: Newsgroups: comp.lang.ada Date: 1997-06-17T00:00:00+00:00 List-Id: On Tue, 17 Jun 1997, Robert A Duff wrote: > Brian Rogoff 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