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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c56a86f3a4e16d06 X-Google-Attributes: gid103376,public From: "Warren W. Gay VE3WWG" Subject: Re: Containers with Ada Date: 2000/11/21 Message-ID: <3A1AAFDE.1FABDD6B@home.com>#1/1 X-Deja-AN: 696236508 Content-Transfer-Encoding: 7bit References: <8v8pii$dvo$1@nnrp1.deja.com> <3A19172D.ACCA08BB@earthlink.net> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii Organization: MetroNet Communications Group Inc. MIME-Version: 1.0 NNTP-Posting-Date: Tue, 21 Nov 2000 10:25:13 MDT Newsgroups: comp.lang.ada Date: 2000-11-21T00:00:00+00:00 List-Id: Stephen Leake wrote: > Brian Rogoff writes: > > > > > > > Rather than telling other people what you'd rather they do, why > > don't you just go do it yourself? If someone wants to create another > > container library in Ada I say "more power to'em!". That ground > > doesn't look old and tired to me. > > Someone looking to create an Ada library should make an attempt to > find out what's already been done. Then they can either just use it, > or improve on it, or start from scratch. In any case, we'll all learn > something (if they tell us :). There are other factors that must be considered before using an EXISTING package: 1. - Who controls its design and interface? 2. - Is it likely to undergo changes in the future? 3. - How stable are the various existing releases of this package out there? If I write an application for donation to the Open Source movement, these are often deciding factors for me. For example, if I write an application based upon the florist package, and the package specs change, then people who try to compile my application are going to whine to me that it doesn't compile. (Actually, the specs need not change-- for example there can be unresolved links in the library etc. leading to other build problems). Many users out there that barely can manage a make command, don't recognize where the problem lies. Consequently, if I suspect that this will be a problem, I'll create my own interfaces that are NOT subject to change (or implementation problems). Even if issues 1 and 2 are resolved, #3 can be a problem. For example if there are many distributions out there with busted florist libraries installed, then I have to either: a) include comprehensive instructions to the user to identify and upgrade the offending packages/libraries.. b) or insulate my application from these problems, to avoid whining emails. Often, I'll choose "b" because my time is too short to help all the users work out issue "a". CONCLUSION: Consequently, only if a package and most of it's existing versions are stable and working, will I consider it for an open source project. For internal projects, this is not really an issue (I can just grumble when it needs adjustment, but then I only need to fix it once -- not for every other user out there). > -- > -- Stephe POSTSCRIPT: This is the reason I think it is VERY IMPORTANT that standards be developed for re-usable components. Once the standard is announced, the developer has some sort of assurance about the interfaces involved, today, and into the future. Warren W. Gay VE3WWG http://members.home.net/ve3wwg