Re: Syntax error when declaring an IBOutlet
Re: Syntax error when declaring an IBOutlet
- Subject: Re: Syntax error when declaring an IBOutlet
- From: Paul Goracke <email@hidden>
- Date: Thu, 6 Mar 2008 12:31:46 -0800
On Mar 6, 2008, at 12:00 PM, Mark Teagarden wrote:
Hi Paul,
I'll bet your World.h includes '#import "Game.h"' which creates an
import cycle when imported from Game.h, but not when imported by
WMapView.h.
Actually, it does. I was concerned that all of these objects needed
outlets
to each other, and that since (in my imperfect understanding) I had to
import the headers of any object I wanted an outlet to point to,
that there
might be some a problem with all of those #imports. Since my
understanding
was that Obj-C uses #import instead of #include specifically to
ensure that
a header was only loaded once, I thought that would solve those
types of
problems.
It does, but that's dependent on it successfully including it in the
first place. It's a fair oversimplification to think of #import (and
even #include) as simply "insert contents of this file right here"
directives; once you hit an include cycle, though, you will never be
able to generate the "all includes inserted" final output for
compilation.
You're not the first coder who has run into this, and you won't be the
last.
2. Why should @class work when #import doesn't? Hillegass flat out
says
that the two are interchangeable.
Where does he say that? I see the following in 2e Cocoa Programming:
You could replace '@class PreferenceController;' with '#import
"PreferenceController.h"'. This statement would import the header,
and
the compiler would learn that PreferenceController was a class.
Because the 'import' command requires the compiler to parse more
files, '@class' will often result in faster builds.
which does _not_ call them interchangeable.
Well, I am perfectly willing to admit that I was wrong
I didn't intend it to be harsh or pedantic. Your statement just seemed
like something rather out of place to put in the mouth of a respected
author, so I was wondering where you found the "flat out" statement.
but frankly I didn't
see anything in there suggesting that they were NOT interchangeable,
especially as there wasn't any discussion of differences between the
two.
In reading it, I felt like @class was simply introduced with no actual
explanation of what it did.
That could definitely be argued. It *is* a statement that makes more
sense in hindsight.
As far as I know, @class just flags that class name as a specialized
version of 'id'. When it comes time to send messages to that object,
you will need to have #imported the header to know its method
signatures. But there are only rare instances when you need to know
those signatures in the header file so defaulting to @class seems to
be the safe way to go.
pg
_______________________________________________
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