Re: respondsToSelector - #import OR compiler warnings?
Re: respondsToSelector - #import OR compiler warnings?
- Subject: Re: respondsToSelector - #import OR compiler warnings?
- From: Graham Cox <email@hidden>
- Date: Tue, 30 Dec 2008 16:00:05 +1100
On 30 Dec 2008, at 3:49 pm, Steve Cronin wrote:
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.
On the contrary, clean compiles with no warnings (even with many extra
warnings enabled) is the hallmark of the meticulous programmer.
Warnings are there to tell you something is probably wrong with your
code, or at least to make you think about issues (like unused
parameters).
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.
You have no choice but to import the headers, or import a secondary
header that contains just those methods, though that might be even
more problematic at some future date. To call those methods properly,
the compiler needs to know about them and it gets that info from the
header. You can't skip it and hope for the best.
I'm not sure why you feel this is a dependency too far - fact is, your
code does depend on those methods and the objects that implement them,
so importing the header is correct. It's not unusual for a .m file to
import dozens of headers. The dependencies are occasionally a nuisance
when porting code to another project but often refactoring of other
code can alleviate it. What you definitely don't want to trap yourself
with is importing more than a very minimal number of headers into a
header - the dependencies that sets up are worse to deal with because
they are not immediately visible.
--Graham
_______________________________________________
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