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,cda33fc7f63c2885 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-01-09 07:57:23 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: list strawman Date: 09 Jan 2002 10:53:27 -0500 Organization: NASA Goddard Space Flight Center Message-ID: References: <4519e058.0201090720.722afa78@posting.google.com> NNTP-Posting-Host: anarres.gsfc.nasa.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: skates.gsfc.nasa.gov 1010591828 27240 128.183.220.71 (9 Jan 2002 15:57:08 GMT) X-Complaints-To: dscoggin@cne-odin.gsfc.nasa.gov NNTP-Posting-Date: 9 Jan 2002 15:57:08 GMT User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 Xref: archiver1.google.com comp.lang.ada:18690 Date: 2002-01-09T15:57:08+00:00 List-Id: dennison@telepath.com (Ted Dennison) writes: > Thomas Wolf wrote in message news:... > > 4. Removing from a list end > > --------------------------- > > You don't always want to get the old element when you remove an item > > from the list. Hence I'd add the following: > > > > procedure Remove > > (Target : in out List; > > List_End : in Direction); > > We are past the point where we can add routines on a whim. People are > actually implementing it and writing code to work with it now. If a > routine is going to be added or changed at this point, it will be only > be for a very good reason (eg: A bug, or a very serious implementation > or usability problem). Well, as a (partial :) implementor, I don't mind this routine; filling in little corners like this is fine. Adding major functionality is not. > > 9. Equality > > ----------- > > Is there any harm done by putting them explicitly in the public part? > > One does not put things in the public part of a package that do not > need to go there. So the proper question for putting things in the > public part of a package is not "Does it do any harm there?", but > rather, "Does it absolutely have to go there?" Again, I think the > proper model here is package Standard, which put a commented-out > version in the public part. It needs to be explicit in either the public or private part of the standard for this package, so that implementers are forced to provide it. If we adopt the rule that "the private part is _not_ specified by this standard" (which makes sense), it _needs_ to be in the public part. Or we can draw a line in the private part and say "everything above this line is defined by the standard". That would be simple. -- -- Stephe