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 11:48:37 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!hammer.uoregon.edu!skates!not-for-mail From: Stephen Leake Newsgroups: comp.lang.ada Subject: Re: List Container Straw Man Date: 07 Nov 2001 14:49:49 -0500 Organization: NASA Goddard Space Flight Center Message-ID: 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: anarres.gsfc.nasa.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: skates.gsfc.nasa.gov 1005162624 10558 128.183.220.71 (7 Nov 2001 19:50:24 GMT) X-Complaints-To: dscoggin@cne-odin.gsfc.nasa.gov NNTP-Posting-Date: 7 Nov 2001 19:50:24 GMT User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 Xref: archiver1.google.com comp.lang.ada:16013 Date: 2001-11-07T19:50:24+00:00 List-Id: "Nick Roberts" writes: > Please make the type List derived from an abstract 'iterator' type. List > would then inherit the iteration operations of this type. An alternative is > for List to provide a function that generates or gives access to an object > derived from this iterator type. > > For example: > > > generic > type Element_Type is private; > > package Containers is > > ... > > type Terminating_Producer is abstract tagged limited private; > > procedure Read (Producer: in out Terminating_Producer; Item: out > Element_Type) is abstract; > > function End_of_Data (Producer: in Terminating_Producer) return Boolean > is abstract; > > ... > > type Sequence_Reproducer is abstract new Terminating_Producer with > private; > > procedure Restart (Reproducer: in out Sequence_Reproducer) is abstract; > > type Sequence_Recorder is abstract new Sequence_Reproducer with private; > > procedure Rewrite (Reproducer: in out Sequence_Reproducer) is abstract; > > procedure Write (Recorder: in out Sequence_Recorder; Item: in > Element_Type) is abstract; > > function Count (Recorder: in Sequence_Recorder) return Natural is > abstract; > > function Is_Recording (Recorder: in Sequence_Recorder) return Boolean is > abstract; > > ... > > end Containers; > > > The Restart procedure tells a sequence reproducer to start producing its > data over again. The Rewrite procedure tells a sequence recorder to start > recording data (at which point Write can be used and Read cannot; > Is_Recording returns True). Restart than tells it to start reading again (at > which point Write cannot be used; Is_Recording returns False). Count returns > the number of items currently recorded. 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? Why are there three (or four) independent types? 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? > package Containers.Lists.Unbounded is > > type Linked_List is new Sequence_Recorder with private; > > -- Representing a singly-linked (forward) list type, with typical > operations. > > function "&" (Left, Right: in Linked_List) return Linked_List is > abstract; Why is this abstract? How many implementations of a singly-linked list are there? Hmm, I guess we have discussed several here, including various options for making Iterators safe. So maybe this makes sense. > ... > > end Containers.Utility.Lists; > > > 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. It also introduces tagged types, which some users might want to avoid (they can have run-time overhead, or be hard to test). 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 :). 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? > 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! -- -- Stephe