comp.lang.ada
 help / color / mirror / Atom feed
From: "Randy Brukardt" <randy@rrsoftware.com>
Subject: Re: overriding in private part
Date: Mon, 6 Oct 2008 18:39:24 -0500
Date: 2008-10-06T18:39:24-05:00	[thread overview]
Message-ID: <gce7k1$3tt$1@jacob-sparre.dk> (raw)
In-Reply-To: wccfxna24b3.fsf@shell01.TheWorld.com

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccfxna24b3.fsf@shell01.TheWorld.com...
> stefan-lucks@see-the.signature writes:
>
>> On Sat, 4 Oct 2008, Robert A Duff wrote:
>>
>>> If you use a compiler that warns on missing "overriding", then you don't
>>> need to say "not overriding", because that's the default -- any
>>> subprogram that doesn't say "overriding" is not overriding.
>>> Saying "not overriding" is just noise.
>>
>> "If you use a compiler that [does the right thing]" (or rather, if you 
>> use
>> that compiler and the right set compiler switches) that works more or 
>> less
>> fine. Except that you get only a warning on something that ought to be
>> treated as an error. (Yes, I know that gnat has a switch to treat 
>> warnings
>> as errors.)
>
> Shrug.  To me, warnings and errors are pretty-much the same.
> At AdaCore, we compile everything in warnings-as-errors mode.
> Not always, but we have procedures in place that ensure no
> Ada code can escape into customer's hands with warnings.

OK, I guess, but I disagree (and agree with Stefan); errors required by the 
language are always more powerful than something done by a specific 
implementation (unless you can be sure that you are never going to use 
another implementation!).

Besides, I don't see how your warning would work with Ada 95 code (such as 
Claw). There's little value to having warnings in such code (it isn't yours 
anyway), but you still would want the errors in your own code. So it seems 
likely that you would have to turn the warning off in large amounts of code; 
that is going to make it more likely that it is also omitted in code where 
you want it to be checked.

>> But a compiler-agnostic way to enforce the proper behaviour (overriding
>> indicators for all the subprograms which actually override another
>> subprogram) would be preferable, IMHO. I wish there was an Ada 05
>>   "pragma Overriding_Indicators_For_All_Oriding_Subprograms"
>> or the like. Or did I overlook something like that in the standard?
>
> I don't think you overlooked anything.  I agree portability is nice, so
> it would nice to have a portable way to say this.  Pragma
> Require_Overriding_Indicators might be a reaonable name.

We couldn't figure out how such a pragma would work with generics. That's 
the main reason this is a three-state switch: "overriding", "not 
overriding", and nothing (which is essentially "don't care"). This may be a 
case where "perfect" prevented "good enough" -- I surely wanted such a 
pragma, but it would have to have enough holes that it wasn't clear that it 
was worth anything.

                                            Randy.






  reply	other threads:[~2008-10-06 23:39 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-02 15:49 overriding in private part Maxim Reznik
2008-10-02 16:42 ` Adam Beneschan
2008-10-03  8:52   ` Dmitry A. Kazakov
2008-10-03 15:54     ` Adam Beneschan
2008-10-03 20:29       ` Robert A Duff
2008-10-04  2:28         ` Randy Brukardt
2008-10-04 19:47           ` Robert A Duff
2008-10-05  7:35             ` Dmitry A. Kazakov
2008-10-05 19:57               ` Robert A Duff
2008-10-06  8:50                 ` Dmitry A. Kazakov
2008-10-06 23:32                   ` Randy Brukardt
2008-10-05 11:46             ` stefan-lucks
2008-10-05 20:08               ` Robert A Duff
2008-10-06 23:39                 ` Randy Brukardt [this message]
2008-10-02 23:17 ` Randy Brukardt
replies disabled

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