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,e5eb8ca5dcea2827 X-Google-Attributes: gid103376,public From: Brian Rogoff Subject: Re: Ada OO Mechanism Date: 1999/05/26 Message-ID: #1/1 X-Deja-AN: 482572674 References: <7i17gj$1u1k@news2.newsguy.com> <7icgkg$k4q$1@nnrp1.deja.com> <3749E9EC.2842436A@aasaa.ofe.org> <7id2eo$fag@drn.newsguy.com> <3749FF7D.F17CE16A@aasaa.ofe.org> <374AC676.F7AE0772@lmco.com> <7ieuja$5v9@news1.newsguy.com> <7igsae$neo$1@nnrp1.deja.com> Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: nntp1.ba.best.com 927774481 228 bpr@206.184.139.136 MIME-Version: 1.0 Newsgroups: comp.lang.ada Date: 1999-05-26T00:00:00+00:00 List-Id: On Wed, 26 May 1999, Robert Dewar wrote: > In article > , > Brian Rogoff wrote: > > Incidentally, I tend to agree with you about automatic > > instantiation, and that was also discussed here. I tend to > > think that it shortens the code > > generally this is an invalid argument from the Ada point of > view, without additional justification that this shortening > makes it easier to *read* and *maintain* the code. Indeed, although I think it safe to say that if it didn't make it any *harder* to read and maintain code, that shortening wouldn't be a bad idea. But that's academic, those factors are seldom (never?) orthogonal. > > by eliminating noise instantiations > > If this really is noise, that does not help the maintainer of > the code, then that is indeed a fair point. However many people > feel (including me) that the explicit instantiations most often > are helpful to the maintainers of the code, and that implicit > instantiations, while allowing neat things to be written, can > generate code that is over-obscure. The same thing can be said for overloading and use clauses too, though I much appreciate overloading and use clauses and feel that used well they leads to easier to read code. Automatic instantiation is in the same category IMO. > As always, talking about generalities is usually useless, and > especially in a case like this, where it depends very much on > the specific case, we should really have a specific case to > talk about. There are a few examples in the Tri-Ada '91 paper "Automatic Instantiation in Ada". Note that the proposal there was an upward compatible extension to Ada 83 which really just made some, not all, instantiations optional. It is also unlike the C++ template mechanism in that it doesn't support things like template metaprogramming. If you look at any of the STL in Ada libraries, you'll also see examples of places where autoinstantiation would be nice. I'll cook up some examples for you, if you find the examples in the Tri-Ada paper unconvincing. I certainly believe from my experiences doing STLish stuff in Ada that such a mechanism would make that style of programming more convenient, and by convenient here I mean for the reader as well as the writer. My experience with ML also has a part in convincing me that a little bit of type inference is OK, though I think that explicit typing is best most of the time. -- Brian