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,88093378be1184d4 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-11-07 16:42:52 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!130.133.1.3!fu-berlin.de!uni-berlin.de!ppp-1-106.cvx5.telinco.NET!not-for-mail From: "Nick Roberts" Newsgroups: comp.lang.ada Subject: Re: List Container Straw Man Date: Thu, 8 Nov 2001 00:06:15 -0000 Message-ID: <9scke9$12jb14$4@ID-25716.news.dfncis.de> References: <9s941p$11mrei$4@ID-25716.news.dfncis.de> <9s99tt$pdb$1@nh.pace.co.uk> <9s9s8p$11vt7l$1@ID-25716.news.dfncis.de> NNTP-Posting-Host: ppp-1-106.cvx5.telinco.net (212.1.152.106) X-Trace: fu-berlin.de 1005180170 36285476 212.1.152.106 (16 [25716]) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Xref: archiver1.google.com comp.lang.ada:16030 Date: 2001-11-08T00:06:15+00:00 List-Id: "Stephen Leake" wrote in message news:u1yjacqea.fsf@gsfc.nasa.gov... > Well, I find this very confusing; there is not enough documentation > for me. > > First, you switched from "Sequence_Reproducer" to "Sequence_Recorder". > Or maybe you left out a type? I made a mistake: in the Print_a_List procedure declaration, I used the type Sequence_Producer when I should have used Terminating_Producer. Sorry. > Why are there three (or four) independent types? Each adds one extra level of functionality. This is vitally important. > How do I write to a > producer object in the first place, so there is something to read? > Conversely, how do I read from a recorder? Remember, an abstract type promises certain operations (and assumed characteristics). The concrete types derived from it must fulfil those promised operations (and should fulfil the characteristics), but nothing stops them adding more operations (and characteristics) of their own! For example, a list type might be derived from Sequence_Recorder, so that its contents can be read using Read and End_of_Data, and then re-read using Restart, and then rewritten using Rewrite and Write. These are the promised operations that the list type must fulfil, but it could add many others (insertion, deletion, whatever). Take another example, a random number generator (RNG). An RNG type might be derived from Sequence_Producer (the most primitive, non-terminating type). This means you can read from it using Read, but there is no end to the data (and no End_of_Data function). 'Read' is the sole promised operation. The RNG type would doubtless add at least one other operation to allow seeding of itself. This is why it is vital to have many types, each adding a small set of extra 'promised' operations. And because objects (values) of both the list type, the RNG type (or indeed any other container type conforming to the design) can be passed straight into any unit which takes one of the abstract iterator types as a parameter, it means you get the 'write once, use anywhere' effect of good software engineering. > > In this way, a piece of software which only needs to iterate over a > > container can be passed any of the list types, or other container types. > > This is true. But it leads to the "complex instantiation" problem that > is one requirement for the list package under discussion. Please see my reply to Marin in this thread. I hope it shows that the instantiations you need (two) are not really all that onerous. > It also introduces tagged types, which some users might want to avoid > (they can have run-time overhead, or be hard to test). I don't think that's true in the great majority of cases. Ada can implement tagged types very efficiently (because it does not have to deal with multiple inheritance). I suppose hard data on this will be hard to get. > Personally, I've never run across a situation where this abstract > container design really made sense; it was always more important to > optimize the implentation for real-time issues (I'm a rocket > scientist, after all :). I use this scheme all the time. I don't think it's unsuitable for most real-time software. Many actual container types will be (but that's a different matter). > In a truly complete library, I think both options should be available; > abstract containers and concrete, simple lists. Perhaps the "Dennison > List" package could be used to implement the doubly-linked list > variant of the abstract container package; would that work for you? For the sake of saving one instantiation? Maybe, but I doubt it. > > Please don't get this elementary aspect of the design wrong! > > "Wrong" is too strong. Just because some people give different design > options different importance does not make them wrong! You're right, of course, but I get a little frustrated at times, Stephe! -- Best wishes, Nick Roberts