comp.lang.ada
 help / color / mirror / Atom feed
From: bobduff@world.std.com (Robert A Duff)
Subject: Re: maintenance of overriding subprograms
Date: 1997/09/08
Date: 1997-09-08T00:00:00+00:00	[thread overview]
Message-ID: <EG7KEv.9tI@world.std.com> (raw)
In-Reply-To: dewar.873631018@merv


In article <dewar.873631018@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>
><<Clearly this error mode can occur without OO programming, but it's
>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




  reply	other threads:[~1997-09-08  0:00 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-09-02  0:00 maintenance of overriding subprograms Stephen Leake
1997-09-05  0:00 ` Robert Dewar
1997-09-05  0:00   ` Stephen Leake
1997-09-05  0:00     ` Matthew Heaney
1997-09-07  0:00     ` Robert A Duff
1997-09-08  0:00       ` W. Wesley Groleau x4923
1997-09-09  0:00         ` Robert A Duff
1997-09-09  0:00           ` Jon S Anthony
1997-09-08  0:00       ` Tom Moran
1997-09-08  0:00         ` Stephen Leake
     [not found] ` <340DCE1D.6C5F@bix.com>
1997-09-04  0:00   ` John G. Volan
1997-09-07  0:00   ` Robert Dewar
1997-09-08  0:00     ` Robert A Duff [this message]
1997-09-09  0:00     ` Dan Johnston D.B.
1997-09-09  0:00       ` Tom Moran
1997-09-09  0:00       ` W. Wesley Groleau x4923
1997-09-10  0:00       ` Robert Dewar
1997-09-11  0:00         ` Dan Johnston D.B.
1997-09-12  0:00           ` Robert Dewar
1997-09-12  0:00           ` Richard A. O'Keefe
1997-09-12  0:00             ` Samuel Mize
1997-09-18  0:00             ` Shmuel (Seymour J.) Metz
1997-09-24  0:00               ` John G. Volan
1997-09-25  0:00                 ` Shmuel (Seymour J.) Metz
1997-09-26  0:00                   ` Richard A. O'Keefe
1997-09-10  0:00 ` Anonymous
  -- strict thread matches above, loose matches on Subject: below --
1997-09-10  0:00 Marc Wachowitz
1997-09-29  0:00 Marin David Condic, 561.796.8997, M/S 731-96
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox