Re: design problem
Re: design problem
- Subject: Re: design problem
- From: Andy <email@hidden>
- Date: Wed, 13 Feb 2002 21:26:34 -0500
email@hidden wrote:
>
>
Hello everybody!
>
>
I have a header file interdependency. A.h imports B.h and B.h imports
>
A.h. Of course, that is not possible, so I am using @class A. The other
>
way around is to use id, however that would add overhead, and I don't
>
want that (since there is a more elegant way of doing it).
>
>
I get a bunch of warnings because the compiler can not find the
>
selectors (apparently since one of the header file is not imported). Is
>
there any way to tell the compiler of the existence of those selectors?
>
An alternative to @class. This is really not all that important, the
>
program runs great, however I hate getting 50 warnings.
>
>
Nick
Yes. Leave things as they are and add
#import "A.h" to your .m file.
That way you avoid the look of A.h imports B.h and B.h imports A.h, but
the compiler can find the types when it comes time to compile the actual
code in the .m files.
In general, I tend to have the A.h import the B.h, and the B.h use
@class A.h. Then I import A.h in B.m.
I choose which way around to do it using the logical design of the
program as a guide, where possible.
Incidentally, many people prescribe to the following scheme:
If A is used in a *public* method of B (ie, one declared in B.h) import
A.h in the header file. However, if A is only used in a private method
(declared in the .m) import B.h only in the .m.
This can cut down on the number of cycles you need to use @class for,
because cycles only occur with if the public methods of 2 classes use
each other.
--
AndyT (lordpixel - the cat who walks through walls)
A little bigger on the inside
I think we finally found the killer app for Flash: animated stick men
_______________________________________________
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.