[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PATCH: Find more ObjC methods
From: |
Ziemowit Laski |
Subject: |
Re: PATCH: Find more ObjC methods |
Date: |
Mon, 6 Oct 2003 11:54:07 -0700 |
On Sunday, Oct 5, 2003, at 07:12 US/Pacific, David Ayers wrote:
Ziemowit Laski wrote:
Example:
@interface Foo
-(void)somePublicMethod;
@end
@implementation Foo
-(void)somePublicMethod {};
-(void)somePrivatMethod {};
-(void)someOtherPrivateMethod
{
[self somePrivateMethod];
}
@end
@implementation Foo (aCategory)
-(void)somePrivatCategoryMethod {};
-(void)someOtherCategoryMethod
{
[self somePrivatCategoryMethod];
[self somePrivatMethod]; /* <- should not see the prototype and
warn! */
}
@end
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?
:-)
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.
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
don't.
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
currently inconsistent.
I thought I _did_ do it for categories as well, but I'll take another
look.
I've opened a bug report:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12516
Ah, I guess I should record my thoughts there, too...
--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
- PATCH: Find more ObjC methods, Ziemowit Laski, 2003/10/02
- Re: PATCH: Find more ObjC methods, Alexander Malmberg, 2003/10/02
- Re: PATCH: Find more ObjC methods, Markus Hitter, 2003/10/03
- Re: PATCH: Find more ObjC methods, Alexander Malmberg, 2003/10/05
- Re: PATCH: Find more ObjC methods, Devang Patel, 2003/10/06
- Re: PATCH: Find more ObjC methods, Ziemowit Laski, 2003/10/06
- Re: PATCH: Find more ObjC methods, Alexander Malmberg, 2003/10/06
- Re: PATCH: Find more ObjC methods, Ziemowit Laski, 2003/10/06
- Re: PATCH: Find more ObjC methods, Pete French, 2003/10/07
- Re: PATCH: Find more ObjC methods, David Ayers, 2003/10/07
- Re: PATCH: Find more ObjC methods, Devang Patel, 2003/10/07
- Re: PATCH: Find more ObjC methods, David Ayers, 2003/10/07
- Re: PATCH: Find more ObjC methods, Pete French, 2003/10/07