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,fdc75443ea18fb32 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-11-29 08:13:38 PST Newsgroups: comp.lang.ada Path: archiver1.google.com!news2.google.com!news1.google.com!sn-xit-02!supernews.com!newsfeed.direct.ca!look.ca!feed2.onemain.com!feed1.onemain.com!uunet!dca.uu.net!ash.uu.net!xyzzy!nntp From: Jeffrey Carter Subject: Re: Standard Queue status X-Nntp-Posting-Host: e246420.msc.az.boeing.com Content-Type: text/plain; charset=us-ascii Message-ID: <3C065B15.5CA7D10B@boeing.com> Sender: nntp@news.boeing.com (Boeing NNTP News Access) Content-Transfer-Encoding: 7bit Organization: The Boeing Company X-Accept-Language: en References: <%QRM7.39743$xS6.65958@www.newsranger.com> <9u0qhb$pq5$1@nh.pace.co.uk> <9u0ujd$rhg$1@nh.pace.co.uk> <3C05E289.C254DA29@mida.se> Mime-Version: 1.0 Date: Thu, 29 Nov 2001 15:58:13 GMT X-Mailer: Mozilla 4.73 [en]C-CCK-MCD Boeing Kit (WinNT; U) Xref: archiver1.google.com comp.lang.ada:17167 Date: 2001-11-29T15:58:13+00:00 List-Id: Mats Karlssohn wrote: > > Ted Dennison wrote: > %< > > Personally, I like his use of the "Direction" type to specify which end to start > > from in his operations. I also like the ability to convert between lists and > > unbounded arrays. I think those may merit putting in the final version. There > > are also a number of operations in there that the strawman doesn't have which > > some folks may find useful. > > Yes, the use of "Direction" is elegant, and converting to and from > unbounded arrays seems useful. I don't know. Specifying the direction seems like control coupling. I don't recall an "unbounded array" in his spec. I recall unconstrained arrays, but that's a different animal. Converting to and from unconstrained arrays is trivial to implement with the standard features of a list, so I'm not sure it should be in the basic package; on the other hand, I'm not sure it shouldn't be there if it's going to be defined at all. > After all one of my general rules is: > "Don't bring in more than you need" > That is, as much as I like nifty features, I want to be able to > pinpoint exactly what facets of an object/alorithm-collection that I > want to bring in for use when solving a problem. Even if > instansiations becomes numerous or _somewhat_ more complicated. There needs to be a balance. After all, the minimum features one needs to build and use an unbounded list are provided by Ada, but I hope no one thinks this is an argument for not having a list ADT. On the other hand, the operations one can think of doing with lists are limited mainly by one's imagination. So the general rule should be something like: include the basic operations, operations that cannot be efficiently implemented without directly manipulating the implementation, and extremely common operations; exclude everything else. The problem is agreeing on "extremely common operations". -- Jeffrey Carter