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,1dd28d5040ded1f8 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-05-13 08:44:13 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: dennison@telepath.com (Ted Dennison) Newsgroups: comp.lang.ada Subject: Re: Announce: Grace project site operational Date: 13 May 2002 08:44:13 -0700 Organization: http://groups.google.com/ Message-ID: <4519e058.0205130744.2602e251@posting.google.com> References: <3CD88FBD.4070706@telepath.com> <3CD91E31.1060004@telepath.com> <3CDBD673.FF452A3D@otelco.net> <3CDD75C7.36C6ADCF@acm.org> NNTP-Posting-Host: 65.115.221.98 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1021304653 14076 127.0.0.1 (13 May 2002 15:44:13 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 13 May 2002 15:44:13 GMT Xref: archiver1.google.com comp.lang.ada:23963 Date: 2002-05-13T15:44:13+00:00 List-Id: Jeffrey Carter wrote in message news:<3CDD75C7.36C6ADCF@acm.org>... > The imported type Element should have the "=" operation imported for it. > > The "=" operations for types List and Iterator should be visible to > clients of the package. I'd like to see more discussion on this point. The way I remember it, we didn't want to add a lot of generic parameters that >%99 of the time would not be used. I can't remember overloading "=" myself, ever. This goes back to the "default generic parameters" issue, but I digress. However, I seem to remember some folks saying that not importing "=" this way causes the built-in equality to reassert itself even after its been overridden. Am I remembering this correctly? > I was interested in seeing the implementation of the "safe" positions > (type Iterator) and was surprised to find that the Remove operation in > the sample implementation does not check for other positions designating > the same node in the list. I see no point in the extra complexity if > it's not used. I haven't looked at it lately, but that sounds like something that it should be doing. The information required to do it is certianly there. -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - http://www.telepath.com/dennison/Ted/TED.html (down)