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,896d86ef3723978c X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: maintenance of overriding subprograms Date: 1997/09/08 Message-ID: #1/1 X-Deja-AN: 270844846 References: <340C2EA5.B9F@gsfc.nasa.gov> <340DCE1D.6C5F@bix.com> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1997-09-08T00:00:00+00:00 List-Id: In article , Robert Dewar wrote: > ><likely to become substantially more common with heavy use of derived >types.>> > >What would be more interesting is to hear from people who have actually >found this to be a problem ... often language experts sit around imagining >things that do not really happen, so the most useful input on errors is >input from people who actually run into them. No, I don't think that works. People who run into errors fix those errors as best they can -- they don't (usually) think about some amazing language change or compiler fix/warning or development technique that could have prevented the problem in the first place. I think it's quite right for "language experts" to imagine things that might happen, and try to prevent them. Think of all the C and Smalltalk programmers who have never encountered a type error. They encounter seg faults, and does-not-understand messages, respectively, but they don't call them type errors, so they don't tend to think, "gee, if only the compiler had ...". >Certainly in the case of GNAT, both the compile time and runtime error handling >and in particular the choice of warnings that are needed are very much >conditioned by user experience in running into problems. > >All the problems Tom Moran mentions can probably be significantly >ameliorated by some additional warning messages, but I would hesitate >to implement such warnings unless I heard from at least one user who >said they had run into trouble. So far, among the thousands of GNAT >users over several years of use, many of whom are not shy about making >suggestions for new messages and warnings :-) no one has commented that >this was a trouble spot. That means nothing. Anyone who hit this bug would naturally (and correctly) assume it was their own fault, and fix it, and then forget it. In any case, warnings are no good (IMHO) if they warn about OK things. In this particular case, I can't see how to warn about the bad cases without also warning about the good. - Bob