respondsToSelector - #import OR compiler warnings?
respondsToSelector - #import OR compiler warnings?
- Subject: respondsToSelector - #import OR compiler warnings?
- From: Steve Cronin <email@hidden>
- Date: Mon, 29 Dec 2008 22:49:57 -0600
Folks;
I have some methods which might be handled by one of several objects.
So I have a set of if ( [objectX
respondsToSelector:@selector(foo)] ) {... } else if ( [objectY
respondsToSelector:@selector(foo)] ) {... } ....
The functionality is fine but the compiler warnings for "no 'foo'
method found" bug me.
Call me finicky if you want but I love spanking clean compiles.
I can, of course, silence the compiler by #import the headers for
ObjectX and ObjectY.
But this leads to a level of dependancy and obfuscation that my gut
doesn't like.
Later I find myself asking "Huh, I wonder why this header is here?"
Or worse: "Dang, I can't just re-use this object here without also
dragging along that object?..arrghh"
So at the moment I add inline comments to the #imports statements to
aid in these later questions but this feels lame and is tedious as
well as error prone.
I realize that the runtime selection of the foo handler is the root
issue and I cannot ignore this when I might reuse.
So I don't want to 'bury' the issue.
But a full header import for the sake of a method or two seems onerous.
What do others think of this dilemma?
Should I just be glad of the warnings and get over it?
Am I getting too worked up on the #import issue?
Is there a compiler flag I could toggle on/off to suit? (XC3.1)
Steve
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden