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,4f316de357ae35e9 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-08-14 12:37:36 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-01!sn-post-02!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: FAQ and string functions Date: Wed, 14 Aug 2002 14:37:23 -0500 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: <20020730093206.A8550@videoproject.kiev.ua> <4519e058.0207300548.15eeb65c@posting.google.com> <20020731104643.C1083@videoproject.kiev.ua> <4519e058.0208010629.5e6182ca@posting.google.com> <20020801194720.Q1080@videoproject.kiev.ua> <4519e058.0208020605.5ab7e092@posting.google.com> <3D4AAF63.72782659@san.rr.com> <3D4B2382.7030209@telepath.com> <3D4B2ACD.FDA29B9A@san.rr.com> <3D4B401E.3060802@telepath.com> <3D4B4477.500088B@san.rr.com> <3D4EA1AC.80D17170@san.rr.com> <3D59B62F.CB30AA51@san.rr.com> X-Newsreader: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3719.2500 X-Complaints-To: newsabuse@supernews.com Xref: archiver1.google.com comp.lang.ada:28030 Date: 2002-08-14T14:37:23-05:00 List-Id: Darren New wrote in message <3D59B62F.CB30AA51@san.rr.com>... >Randy Brukardt wrote: >> I think your missing the Ada philosophy that something expensive should >> look expensive. An unbounded array (as you put it) is going to be >> expensive, and that expensive shouldn't be covered up in glossy syntax. > >So you feel that including Ada.Strings.Unbounded as a standard part of the >language was unwise? That everyone should rewrite that library so everyone >knows how difficult and inefficient it is? No, to both questions. Ada.Strings.Unbounded is useful because it provides a lot of useful functionality beyond "unboundedness". The "unboundedness" alone is (IMHO) insufficient reason for a library. That is especially true as other types of arrays are much less likely to be modified repeatedly than strings. And the cost of access (which requires copying) is usually not an issue with strings (copying characters is cheap). Moreover, other types of arrays are rarely an abstraction unto themselves as strings are, so I believe that the entire thing (including the unbounded array) should be encapsulated in that larger abstraction. No, writing unbounded arrays is not difficult in Ada. The idiom for making "unbounded" array objects in Ada is so fundamental that it should be learned early by Ada programmers. And it is so simple that no one should need a crutch (a library) to do it. It is ineffecient (because of all of the calls to New and Free), and writing it explicitly makes that obvious -- and also encourages the programmer to minimize these costs (certainly Perl's syntax does not do that!). The only advantage of a library is improved memory management (can't leak memory), but it makes indexing and slicing harder and more expensive (as the data must copied for each operation - which may be quite expensive). It is rare (other than in quick and dirty programs, not what Ada is for) that the performance hit in access can be justifed for the ease of memory management. I don't object to a library (it looks expensive enough), but I wouldn't use it. Doesn't stop you from using it. And I don't think it would satisify anyone that wants Perl-like consiseness - for that you would have to have native syntax. But native syntax would definitely violate the philosophy in this case. So, I don't see the value - it's not going to attract scripting language users to Ada. But this isn't the only supposedly important area of Ada that I don't see the value of; certainly everyone's priorities differ, and I certainly wouldn't oppose adding such a thing to the standard if a decent design was proposed. Randy Brukardt.