Re: Compiler Warning City
Re: Compiler Warning City
- Subject: Re: Compiler Warning City
- From: Kirk Kerekes <email@hidden>
- Date: Sat, 26 Oct 2002 11:53:30 -0500
I just tested the following kluge-around code, and it works.
The premise is that "id" is (to the compiler) a synonym for (NSObject
*), so if I append methods to NSObject's interface via the interface
portion of the category scheme, the compiler stops complaining.
Thus:
@interface NSObject (IdMethods)
- (void) _setAvoidsActivation:(BOOL) value;
@end
lets me call:
{
id test = [self window];
[test _setAvoidsActivation:YES];
}
-- with no compiler warnings at all. Use of any other non-NSObject
method on id still generates the appropriate warning.
Note that this doesn't actually create a category on NSObject -- it
just goofs the compiler into assuming that the category exists at
compile time.
This is pretty much like declaring that NSObject subscribes to a
protocol that has all of your id-methods in it.
Indeed:
@protocol IdStuff
- (void) _setAvoidsActivation:(BOOL) value;
@end
in a .h file, followed by:
@interface NSObject (idMethods) <IdStuff>
@end
-- at the top of your .m file
-- accomplishes exactly the same result -- no warnings.
This protocol-category hybrid gives you some nice control -- you can
selectively determine what methods are legit for id in any one .m file
by putting the NSObject interface declarations at the top of the .m
file. This lets you _selectively_ squish compiler warnings that you
know are bogus, while keeping the general protection of static typing
with id messaging. I feel that this is preferable to turning off static
typing, even if you can do it just for "id"s.
With the protocol based version, one could easily create multiple
separate protocols for NSObject as appropriate for specific sections of
your code, and #import them as needed to squelch inappropriate compiler
warnings.
Then at the top of the .m file, you put:
@interface NSObject (idMethods) <IdStuff,OtherIdStuff>
@end
I stumbled into this trying to get rid of compiler warnings when
calling Appkit methods that I'm not _supposed_ to be using, as you can
tell from the example method used above.
Combine the above methods with creative use of #define, and you can
have id-typing control at whatever level of detail you might want.
Of course you could simply embed lines like:
#define id (NSWindow *)
#undef id
-- in your code also.
Or use casts. But these lower-tech solutions aren't as generally useful
when you have really "id-iomatic" code.
On Thursday, October 24, 2002, at 06:48 PM,
email@hidden wrote:
Date: Thu, 24 Oct 2002 17:20:40 -0400
Subject: Compiler Warning City
From: G Douglas Davidson <email@hidden>
To: email@hidden
Is there any way to use type "id" and not get two compiler warnings per
usage?
1. warning: cannot find method
2. warning: return type for "whatever:" defaults to id
There are some times where I don't want or can't easily use static
typing, and it would be really nice if the compiler could say "Hey, its
type 'id', that means he does not want warnings about methods (which
would be impossible anyway) and warnings about return types (which
would also be impossible.)" Ideally I'd like the compiler to check on
the static stuff and not on the type "id" stuff.
Is this possible?
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.