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=0.6 required=5.0 tests=BAYES_00,TO_NO_BRKTS_FROM_MSSP autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e382b50ddc696050 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-12-06 08:11:26 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news-out.visi.com!hermes.visi.com!newsranger.com!www.newsranger.com!not-for-mail Newsgroups: comp.lang.ada From: Ted Dennison References: <3C0DB9D0.7184868A@acm.org> <3C0EB851.77E7172A@boeing.com> Subject: Re: List Strawman JC01 Message-ID: X-Abuse-Info: When contacting newsranger.com regarding abuse please X-Abuse-Info: forward the entire news article including headers or X-Abuse-Info: else we will not be able to process your request X-Complaints-To: abuse@newsranger.com NNTP-Posting-Date: Thu, 06 Dec 2001 11:11:09 EST Organization: http://www.newsranger.com Date: Thu, 06 Dec 2001 16:11:09 GMT Xref: archiver1.google.com comp.lang.ada:17511 Date: 2001-12-06T16:11:09+00:00 List-Id: In article <3C0EB851.77E7172A@boeing.com>, Jeffrey Carter says... > >Ted Dennison wrote: >> be better to put this information in a matrix in the parent pacakge so that >Except we're talking about one package for unbounded lists. In the case >of this strawman, there's no parent package. Not true. Since the name is "Containers.Lists.Unbounded", there are actually *two* parent packages. I'm compiling the strawman before I post it, so those packages do exist. Its just that there isn't anything in them to look at yet, so I haven't bothered to post them. :-) How about I add a 1-row "matrix" to the top of the package for now, with a note that it will get moved to the parent when there are more rows? >that, we can decide what notation to adopt. If we want a bounded list >package at some point with similar semantics, we probably will need list >parameters. That may be an issue, but it doesn't have to be done that way. We could decide to still keep a pointer to the list in the iterator, which would allow the same iterface as the current Unbounded strawman. But that's a discussion for another time. >> > Storage_Exhausted : exception; >> >> Why is this considered superior to STORAGE_ERROR? Do you have plans to do >> something here other than just handle STORAGE_ERROR and raise Storage_Exhausted? > >As a general principle, a package should not be propagating predefined >exceptions to its clients. Also, this helps allow differing By "predefined" I take it you mean "declared in the standard Ada libarary somewhere". Considering that the ultimate goal of this facility is to be part of the standard Ada library, I don't think your principle applies here. :-) Personally I don't really subscribe to that principle anyway. You should certianly change the exception if the one raised isn't at the appropriate level of abstraction for the user. This will, in practice, amount to the same principle as yours. For instance, I wouldn't allow Ada.IO_Exceptions.Name_Error to be propagated out of a log file facility. I'd change it to something like Logfile.Unavailable or Logfile.Installation_Error, because those better describe the condition causing the problem. Also, the fact that Ada's IO facilities are used (rather than system calls or something) is an implementation detail that the user doesn't care about. By this same principle you clearly wouldn't want to allow Contraint_Error due to in internal calculation out of your routine either. But this is quite different. Dynamic allocation is clearly going on here, and Ada.Storage_Error perfectly describes the problem (as evidenced by the fact that your name for it is hardly different at all). >This is much less clear than "<". Everyone knows what "<" does. >"Swap_Items (L, R ...) return Boolean;" is meaningless. In the context of a boolean expression, yes everyone knows. In the context of the internals of a sort routine, its completely undefined. Is the "Left" parameter the "Front" side or the "Back" side? Does a "True" result mean its out of order or in order? You can supply answers to these questions I'm sure, but the answers will be fairly arbitrary. They are certianly not self-evident. >Is the array > >(1, 2, 3, 4) > >in ascending order? The answer is obvious to most people, because an >array is a sequence. No, its obvious to most people because the array is indexed by a discrete type, upon which the "<" operator is defined. Thus the convention that ascending order is the order in which items whose indexes return True for ">" will also have values return true for ">" can be applied. We have no such relationship for our doubly-linked list. "<" is not defined on iterators. "Next" requires a direction parameter to disambiguate. The only ordering a doubly-linked list has is the one the user puts upon it. I could look at the list left to right, right to left, top to bottom, bottom to top, and no one can say my view is wrong. I can iterate from front to back or back to front and it won't make any real difference. The only directional terminology we have at all is "Front" and "Back". For anything directional to make sense at all, it *must* be cast in those terms. "<" is not cast in those terms. >the First element, the Next element, the Next element, ... , the Last .. >First and Second are perfectly well defined for a list. The first >element in List is designated by First (List); the second by Next (First You are probably thinking of a singly-linked list. That makes a bit of sense for a singly-linked list because there is only one way you can iterate. Therefore we know what ascending order is, because there's only one direction to traverse the list. For a doubly-linked list, either end is equal. There may be an ordering, but the direction of it is entirely imposed by the user. I'll ask you to go look at the spec again. There is no "First" function, only a "Side" function, which takes a directional parameter to disambiguate. "Next" also requires a directional parameter to disambigute. --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html No trees were killed in the sending of this message. However a large number of electrons were terribly inconvenienced.