This is the mail archive of the
mailing list for the GCC project.
Re: PATCH: Find more ObjC methods
- From: Ziemowit Laski <zlaski at apple dot com>
- To: David Ayers <d dot ayers at inode dot at>
- Cc: Markus Hitter <mah at jump-ing dot de>, Alexander Malmberg <alexander at malmberg dot org>, discuss-gnustep at gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Mon, 6 Oct 2003 11:54:07 -0700
- Subject: Re: PATCH: Find more ObjC methods
On Sunday, Oct 5, 2003, at 07:12 US/Pacific, David Ayers wrote:
Ziemowit Laski wrote:
Fine, I must admit for large files with multiple categories the old
behavior gives a reassurance that such methods are only used within
the corresponding category. But if you must, then collect all
implementations prototypes of a class.
@implementation Foo (aCategory)
[self somePrivatMethod]; /* <- should not see the prototype and
No, here is where I disagree. Clearly, the compiler has seen the
@implementation containing the method in question, so it knows it is
there. Not sure why you'd want the compiler to look the other way?
Yet the implementation you have committed is broken, as it goes way to
far. Actually, it's even inconsistently broken. You're making these
private prototypes globally visitable (i.e. to code outside of the
class) by adding it to the @interface structure.
The fix is broken in one respect (hopefully seen only rarely) --
namely, if there is no @interface at all (only an @implementation),
then we do not have a place to attach the prototypes to, and so we
However, I must stress again that Objective-C does not have a notion of
"private prototypes". In addition, if you do see an @implementation of
a method (whether in a class or a category thereof), it is perfectly
acceptable to call it from within the same module, since the module
will be loaded in its entirety.
Feel free to /use/ the prototype (as that is what the runtime will
do), but *do* emit a warning when they are used outside of the class.
Since there are no private methods, it does not and should not matter
whether or not they are called outside of the class or not. :-)
And if you start pooling prototypes please. also do it for category
implementations, as this is where the broken implementation is
I thought I _did_ do it for categories as well, but I'll take another
I've opened a bug report:
Ah, I guess I should record my thoughts there, too...
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