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,ce0900b60ca3f616 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-11-02 07:07:19 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: <9rti6v$hcu$1@news.huji.ac.il> Subject: Re: List container strawman Message-ID: <1EyE7.10050$xS6.13527@www.newsranger.com> 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: Fri, 02 Nov 2001 10:06:37 EST Organization: http://www.newsranger.com Date: Fri, 02 Nov 2001 15:06:37 GMT Xref: archiver1.google.com comp.lang.ada:15643 Date: 2001-11-02T15:06:37+00:00 List-Id: In article <9rti6v$hcu$1@news.huji.ac.il>, Ehud Lamm says... >1. In my scheme "Element" is a generic parameter of the top package >(Containers), and not of the specific implementations. >(Remember, my attemp for having interface inheritance) I didn't do that because that is precisely what Booch does that makes it so complicated to use. If one does that, then proper use of the package would require 3 cascading generic package instantiations. If that is OK, then in my opinion we should just bag this whole thing and use Booch. >2. Why is List private? Shouldn't it be limited private, so we avoid >possible erros caused by aliasing? First off, I'd like to note for anyone who may have missed it, that any Element passed in to be put on a list or taken off of one will be *copied*. Pointers to elements will not be used. If List were limited private, then we'd have to get rid of all those "&" routines. My thinking was that Lisp-like functional list processing would be desirable. You could indeed have aliasing problems, but only if your Element type uses pointers. Having "&" avaliable also makes list operations somewhat consistent with arrays, which also have "&". However, any use of those "&" routines will involve creating a copy of every element (much like using "&" with arrays does). That would probably be too expensive in most cases, so perhaps it really isn't all that valuable. I'm curious how others feel about this. >(If the majority wants private, at least the spec should mention the >possbile problems) I can agree with this. At the least there should be some sort of warning in there about using pointers in Element with those routines. >3. "Construct" is indeed a long name. We can, as part of the library, decide >on some standard name for this like - or + As the comment said, I seriously considered that. However, it is not (yet) a common idiom to use those for constructors. So I'm not sure if it would help or hurt readability. Again, I'm curious what people think about this. >4. I've seen many implemenations that paremtrize Insert and Remove with a >direction parameter, instead of having seperate routines (_Back/_Front). I >am not sure I know which approach I prefer... >5. Front() and Back() raise execption on Empty List? Assuming you are talking about the iterator routines "First" and "Last", that's a good point. I seem to have totally neglected that case, and thus left serious problems in there. For instance, the comment that says "For an empty list, First = Last." is clearly wrong. That would indicate a list with one element, not an empty one. I'll have to redo the iterators somehow... >6. I like having a "No_More_Elements()" operation as part of the Iterator >interface. It saves time compared to Size (for containers that don't keep >count of size), and I don't like programming with exceptions ("exceptions >for control flow"). That seems sensible. And I agree about using exceptions, which is why it is only one example of 3. That stuff is all wrong anyway though... >7. Sort should be in a child unit. Why do you feel that way? What does putting it off in a separate unit gain you? > >Finally, a more general question: >Is this a DeQueue or a Doubly-linked list? Should these be two different >abstractions? (IMO: Yes, they should). What specificly would the difference be? Clearly it would have to be doubly-linked to support all those push and pop operations, and both Next and Previous as iterators. You could implement those on a singly-linked list, but it wouldn't be very efficient. --- 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.