This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: Find more ObjC methods
- From: Ziemowit Laski <zlaski at apple dot com>
- To: Alexander Malmberg <alexander at malmberg dot org>
- Cc: discuss-gnustep at gnu dot org, gcc-patches at gcc dot gnu dot org, Devang Patel <dpatel at apple dot com>, David Ayers <d dot ayers at inode dot at>, mah at jump-ing dot de, Pete French <pete at twisted dot org dot uk>
- Date: Tue, 7 Oct 2003 11:52:46 -0700
- Subject: Re: PATCH: Find more ObjC methods
On Tuesday, Oct 7, 2003, at 10:27 US/Pacific, Alexander Malmberg wrote:
Devang Patel wrote:
On Oct 7, 2003, at 3:08 AM, David Ayers wrote:
So even if this isn't reverted (and I do conceed to the new behavior
in the sense that it is /using/ the prototype), I hope a patch that
will introduce an optional warning with a more accurate warning would
be acceptable.
[snip]
Now, with this background lets discussion current issue.
Before Zem's recent patch, GCC had bug in the sense it used to
warn 'foo may not respond to bar'
The wording was misleading, and could be considered a bug. However, the
presence of a warning was no bug.
No, it was not misleading; it was unambiguously, 100% wrong. Seeing
an actual @implementation gives you a guarantee that no mere @interface
can ever give you.
in situations where, it can
determine that foo responds to bar. So now GCC does not
issue warnings in such cases. And we are discussing in this
thread whether we should add new command line option to
enable 'wrong' compiler warnings.
The warning isn't wrong unless you don't want to follow this convention
(methods declared only in an @implementation are private to that
@implementation).
No, it's _still_ wrong :-) And, for the n-th time, allow me to
reiterate the
fact that Objective-C has _no_ private methods (because your precious
"private"
method _will_ get called by the runtime).
As David Ayers and I have explained, we find this convention, and the
support from the compiler in adhering to it, useful. If you don't,
you're free to not enable/disable the warning (note "optional").
I do not approve such patch.
Why? The warning would be optional, so doing this gains you nothing, it
merely prevents those who do want the warning from getting it. It seems
that you want to remove a feature that others use just because you
don't
use it, which is not a particularly nice attitude.
As I said before, you're more than welcome to offer a patch that will
give you the warning you want. But the warning you used to get until
recently was outright wrong.
--Zem
--------------------------------------------------------------
Ziemowit Laski 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group Cupertino, CA USA 95014-2083
Apple Computer, Inc. +1.408.974.6229 Fax .5477