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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8eff44ec1bcf8433 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-10-21 11:19:04 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!canoe.uoregon.edu!hammer.uoregon.edu!skates!not-for-mail From: Stephen Leake Newsgroups: comp.lang.ada Subject: Re: Container reqs Date: 21 Oct 2001 14:17:14 -0400 Organization: NASA Goddard Space Flight Center Message-ID: References: <9qctpn$lil$1@news.huji.ac.il> <3nCy7.29644$ev2.35903@www.newsranger.com> <9qfgla$7sb$3@news.huji.ac.il> <9qnflg$pm$1@news.huji.ac.il> <3BCF57C8.DE99D9C@boeing.com> <9qpf0c$5ko$1@news.huji.ac.il> NNTP-Posting-Host: anarres.gsfc.nasa.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: skates.gsfc.nasa.gov 1003688361 5975 128.183.220.71 (21 Oct 2001 18:19:21 GMT) X-Complaints-To: dscoggin@cne-odin.gsfc.nasa.gov NNTP-Posting-Date: 21 Oct 2001 18:19:21 GMT User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 Xref: archiver1.google.com comp.lang.ada:15000 Date: 2001-10-21T18:19:21+00:00 List-Id: "Ehud Lamm" writes: > Stephen Leake wrote in message > news:un12nod47.fsf@gsfc.nasa.gov... > > Jeffrey Carter writes: > > > > > Ehud Lamm wrote: > > > > > > > > What I dodn't like is the need for several, possibly nested, > instantiations > > > > simply to get a simple queue or hash table. > > > > > > I wholeheartedly agree. Wright's posting here a few days ago of the > > > sequence of instantiations needed to obtain a simple structure with the > > > Booch components clearly indicates that they fail this requirement. > > > > This is easy to say. But can you provide an alternative, that still > > allows the container to handle all reasonable Ada types? > > > > People have made the same complaint about my library. But that > > complexity is simply a reflection of the complexity that Ada supports. > > I don't see a simple alternative that is not so restrictive as to be > > useless. Well, you could maintain several copies of the code, each > > accepting slightly different generic formal types. But _I'm_ not going > > to do that! > > > > > Yep. I agree entirely.

> But since I find this point to be important for using the library in > education, I wanted to hear ideas and possible solutions.

> What I was thinking about was having wrapper packages, for the most > important cases. I don't think this will turn out to be a mjor overhead. And > it should ease the learning curve, even for experts, since these packages > will be, in essence, example code... Well, examples are always useful. And I have helper packages to make things simpler in the "simple" cases. There is test code that serves as examples for my library; other examples would probably be helpful. Perhaps you could volunteer to define the "typical most important cases", and I'll write example code for them, for my library. If it seems reasonable, I'll also try to write a "simple wrapper" package. Then someone else can try to do the same with each of the other candidate libraries. That should be a good learning exercise. It might also make it easier for potential users to compare the libraries: "Let's see. It takes 42 lines and 5 packages to get a list of integers with SAL, and 52 lines in 3 packages with BC. Which should I use?" Hopefully it won't be that simplistic :). Hmm. I suppose more learning would occur if we each did the examples for someone _else's_ library. But I don't have the time ... -- -- Stephe