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, David Ayers <d dot ayers at inode dot at>, Markus Hitter <mah at jump-ing dot de>
- Date: Mon, 6 Oct 2003 12:08:06 -0700
- Subject: Re: PATCH: Find more ObjC methods
On Sunday, Oct 5, 2003, at 07:52 US/Pacific, Alexander Malmberg wrote:
We really have two issues here:
1. Behavior. Should the compiler use prototypes of methods declared
only
in an @implementation outside that @implementation?
If the @implementation is visible (i.e., we are in the same translation
unit), yes. Why not?
2. Warning. Should the compiler warn when a method declared only in an
@implementation is used outside that @implementation?
If you're in a different translation unit, then obviously you'll still
get a warning since the compiler won't see the method. If you're in the
same translation unit, then not only do you see the method, but its
runtime availability is statically decidable. So I'm not sure what it
is you'd want to warn about.
Currently, we achieve (2) through (1). The patch changes (1), and thus
we lose (2).
(2) is a convention, but a very useful convention, and it's used a lot
in eg. GNUstep.
And what does this convention buy you? You wind up warning about
methods
that are _always_ available! :-)
The compiler should, IMO, warn about this. I don't care
much about (1), though, and using the prototype does make sense from a
consistency pov.
Thus, I'm ok with changing (1) to find the prototype, as long as the
warning remains (optionally, at the very least, and I guess, reworded).
Certainly; 'foo may not respond to bar' is completely bogus in this
case. :-)
Perhaps in the future, when we unify the the ..._INTERFACE_TYPE and
..._IMPLEMENTATION_TYPE
data structures, we can also define a METHOD_HAS_PROTOTYPE() bit in
..._METHOD_DECL, and you
guys could key off of that to generate the (newly-worded) warning?
This would have to be
enabled via a flag, since our resident NeXTies would almost certainly
_not_ want to see this
warning. :-(
--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