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,88b676af04f3073d X-Google-Attributes: gid103376,public From: cgreen@yosemite.atc.com (Christopher Green) Subject: Re: Ada generics are bad Date: 1998/04/13 Message-ID: <6gs5qa$s46@newshub.atmnet.net>#1/1 X-Deja-AN: 343499166 References: <6gm6jc$fbp@newshub.atmnet.net> Organization: Advanced Technology Center, Laguna Hills, CA Newsgroups: comp.lang.ada Date: 1998-04-13T00:00:00+00:00 List-Id: In article , Robert Dewar wrote: >Chris Green says > ><does not obsolete units that instantiate it or depend on instantiations, >and it is possible to deliver libraries that include only object code >for such bodies (this is a key concern for developers of commercial Ada >software such as ourselves, who are wary of releasing more source code >than we absolutely have to). >>> > >Very often an approach that works well is to isolate the "generic" parts >of the body, and use common code for the non-generic parts. Look at the >GNAT code for an example of how this is done, in particular, look at >the code for Float_IO. Almost nothing of interest is in the generic itself, >all the "good stuff" is in the common units. All good; however, sometimes one is stuck with maintaining existing code that was not written with an eye to isolating generics in packages that are not widely depended upon. Then one finds, as the original poster did, that updating the generic body has a high cost in recompilation of other, often quite unrelated, code. Function-form generics and compilers with smart recompilation are helpful in dealing with this kind of problem, though they are no substitute for doing good design up front. >This could be used to "solve" the "problem" of releasing more source code >than you absolutely have to, although from a users point of view, using >libraries where you do not have the source and do not know what is going >on seems pretty dubious. I suppose if the only option you have is to use >closed software of this kind, then the risk may be acceptable. Such closed software is standard (though far from universal) practice in the commercial "C" world. Whether it is desirable is a different question entirely: from the de- veloper's point of view, the more control retained over the source, the better; from the user's point of view, the more access to the source, the better. The marketplace has a way of forcing sellers and buyers to reach reasonable compromises. -- Chris Green Email cgreen@atc.com Advanced Technology Center Phone (714) 583-9119 22982 Mill Creek Drive ext. 220 Laguna Hills, CA 92653 Fax (714) 583-9213