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,f51e93dacd9c7fca X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-10-01 11:44:59 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!sn-xit-03!sn-xit-06!sn-post-02!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: status of Ada STL? Date: Tue, 1 Oct 2002 13:41:47 -0500 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: <3d0f0c40_1@news.tm.net.my> <3D95E5F7.CE1669E9@adaworks.com> X-Newsreader: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3719.2500 X-Complaints-To: abuse@supernews.com Xref: archiver1.google.com comp.lang.ada:29444 Date: 2002-10-01T13:41:47-05:00 List-Id: Marin David Condic wrote in message ... >I'm curious about what you're looking for archtecturally? Some sort of >breakdown of library domains? (e.g., "Containers", "Mathematics", "OS >Services", etc.) A breakdown of implementation concepts? (Dynamic vs Static, >Generic vs Object Oriented, etc.) Or just a breakdown of desired >functionality? ("A list container will have the following types, operations, >etc.") Speaking for myself (not for the ARG!), I'd like to see an agreed on list of requirements for the library. That would make it easier to evaluate proposals/existing libraries. For example, my number one requirement is ease-of-use. I expect the primary use of these containers would be in prototypes and non-critical code, and also by programmers relatively new to Ada. For those uses, ease of use is more important than expressive power or top shelf performance. After all, if it is harder to use the components than it is to roll-your-own, no one will use them. (That is my objection to the original Booch components - haven't looked at them recently). Ada.Strings.Unbounded is designed that way, so it would be consistent to do that with libraries as well. >.. >Something the vendors would package with their compilers on an "As Is" basis >with the only promise being that most/all implementations of Ada come with >this library and the only guarantee is the package spec - behavior may vary >some. That is not going to happen. Speaking for RR Software, if we provide it, we're going to support it. If you want something else, get it from AdaPower. We're not going to provide an "as-is" code. Period. Moreover, I doubt that anything that doesn't have defined behavior is going to be portable in any practical way. You're better off downloading the code from AdaPower, because then you'll have the code, and it can be ported (hopefully) without changes. >This isn't far afield from what other languages have done in the past >and continue to do ... The best suggestion I've seen here is to provide a semi-official library of code similar to Java's. This keeps the vendors out of it (beyond making sure that the code compiles). And the user is not mislead about the status of the code. The main question with this idea is who is going to sponser it and fund it? That's being actively studied -- hopefully a solution will be found. Randy Brukardt