Warning: 'Class' does not respond to 'method'

[C Lund]

I have three classes: Map, which accumulates NSMutableArrays of the
other two classes, Surface and Vertex. Communication between Map and
the other two classes works fine. But Surface and Vertex needs to keep
pointers to instances of each other. The pertinent part of the header
files (afaik) are:

------------------

Map.h:

#include "Surface.h"
#include "Vertex.h"

@interface Map : NSObject
{
NSMutableArray *surfaceList;
NSMutableArray *vertexList;
}

@end
------------------

Surface.h:

@class Vertex;

@interface Surface : NSObject
{
Vertex *vertexList[3];
Surface *surfaceList[3];
}

@end
------------------

Vertex.h:

@class Surface;

@interface Vertex : NSObject
{
GLfloat vertexCoord[3];
NSMutableArray *surfaceList;
}
-(GLfloat)coord:(int)index; //returns vertexCoord[index]

@end
------------------

If I try to call [vertexList[0] coord:0] from an instance of Surface,
PB gives me a 'Vertex' does not respond to 'coord:'.

What am I doing wrong here?

--
C Lund, [url]www.notam02.no/~clund[/url]

[matt neuburg]

In <clund-D1DC50.14051623082003@amstwist00.chello.com> C Lund wrote:

> If I try to call [vertexList[0] coord:0] from an instance of Surface,
> PB gives me a 'Vertex' does not respond to 'coord:'.
> What am I doing wrong here?

You probably didn't #import Vertex.h into the file where you're making
this call. m.

--
matt neuburg, phd = [email]matt@tidbits.com[/email], [url]http://www.tidbits.com/matt[/url]
REALbasic: The Definitive Guide! 2nd edition!
[url]http://www.amazon.com/exec/obidos/ASIN/0596001770/somethingsbymatt[/url]
Subscribe to TidBITS. It's free and smart.

[C Lund]

In article <20030823081318400-0700@news.la.sbcglobal.net>,
matt neuburg <matt@tidbits.com> wrote:

> In <clund-D1DC50.14051623082003@amstwist00.chello.com> C Lund wrote:

> > If I try to call [vertexList[0] coord:0] from an instance of Surface,
> > PB gives me a 'Vertex' does not respond to 'coord:'.
> > What am I doing wrong here?

>
> You probably didn't #import Vertex.h into the file where you're making
> this call. m.

No, I didn't. The problem is that I will also be calling Surface
methods from Vertex, and if I import both class headers into each
other (I've tried this) I get a bunch of errors involving previous
declarations, conflicting types, duplicate interface declaration
warnings, and so on. Both classes need to be able to call each other's
accessor methods.

--
C Lund, [url]www.notam02.no/~clund[/url]

[C Lund]

In article <clund-6121D9.18230423082003@amstwist00.chello.com>,
C Lund <clund@NOSPAMnotam02.no> wrote:

> In article <20030823081318400-0700@news.la.sbcglobal.net>,
> matt neuburg <matt@tidbits.com> wrote:

> > You probably didn't #import Vertex.h into the file where you're making
> > this call. m.

> No, I didn't. The problem is that I will also be calling Surface
> methods from Vertex, and if I import both class headers into each
> other (I've tried this) I get a bunch of errors involving previous
> declarations, conflicting types, duplicate interface declaration
> warnings, and so on. Both classes need to be able to call each other's
> accessor methods.

Well, I'll #import Vertex.h in Surface for now. That works for now
anyway. Maybe I can avoid calling Surface methods from Vertex.

--
C Lund, [url]www.notam02.no/~clund[/url]

[Michael Ash]

In article <clund-6121D9.18230423082003@amstwist00.chello.com>,
C Lund <clund@NOSPAMnotam02.no> wrote:

> In article <20030823081318400-0700@news.la.sbcglobal.net>,
> matt neuburg <matt@tidbits.com> wrote:
>

> > In <clund-D1DC50.14051623082003@amstwist00.chello.com> C Lund wrote:

> > > If I try to call [vertexList[0] coord:0] from an instance of Surface,
> > > PB gives me a 'Vertex' does not respond to 'coord:'.
> > > What am I doing wrong here?

> >
> > You probably didn't #import Vertex.h into the file where you're making
> > this call. m.

>
> No, I didn't. The problem is that I will also be calling Surface
> methods from Vertex, and if I import both class headers into each
> other (I've tried this) I get a bunch of errors involving previous
> declarations, conflicting types, duplicate interface declaration
> warnings, and so on. Both classes need to be able to call each other's
> accessor methods.

Here's the proper way to do this in ObjC.

If you need to inherit from a class, #import it in your .h file.

If you need to reference a class in a .h file but not inherit from it,
use @class Class.

If you need to send messages to objects of a class where you just did
@class Class in your .m file, also #import it in your .m file.

This last one is important. It's how you avoid circular #imports and
everybody goes home happy.

[Tom Harrington]

In article <clund-6121D9.18230423082003@amstwist00.chello.com>,
C Lund <clund@NOSPAMnotam02.no> wrote:

> In article <20030823081318400-0700@news.la.sbcglobal.net>,
> matt neuburg <matt@tidbits.com> wrote:
>

> > In <clund-D1DC50.14051623082003@amstwist00.chello.com> C Lund wrote:

> > > If I try to call [vertexList[0] coord:0] from an instance of Surface,
> > > PB gives me a 'Vertex' does not respond to 'coord:'.
> > > What am I doing wrong here?

> >
> > You probably didn't #import Vertex.h into the file where you're making
> > this call. m.

>
> No, I didn't. The problem is that I will also be calling Surface
> methods from Vertex, and if I import both class headers into each
> other (I've tried this) I get a bunch of errors involving previous
> declarations, conflicting types, duplicate interface declaration
> warnings, and so on. Both classes need to be able to call each other's
> accessor methods.

I'd guess this problem arises from the fact that your Map.h snippet
shows you including both Surface.h and Vertex.h. Any reason not to
change those into @class declarations? Does Map.h really need to know
the full interface of Vertex and Surface, or is it enough for it to just
know that they exist?

--
Tom "Tom" Harrington
Macaroni, Automated System Maintenance for Mac OS X.
Version 1.4: Best cleanup yet, gets files other tools miss.
See [url]http://www.atomicbird.com/[/url]

[C Lund]

In article <mail-1A9964.12161223082003@localhost>,
Michael Ash <mail@mikeash.com> wrote:

> Here's the proper way to do this in ObjC.
>
> If you need to inherit from a class, #import it in your .h file.
>
> If you need to reference a class in a .h file but not inherit from it,
> use @class Class.
>
> If you need to send messages to objects of a class where you just did
> @class Class in your .m file, also #import it in your .m file.

You mean @class Class in the *header* file, right? Because that way it
works.

> This last one is important. It's how you avoid circular #imports and
> everybody goes home happy.

I am anyway. Thanks. B)

--
C Lund, [url]www.notam02.no/~clund[/url]

[Michael J Ash]

On Sat, 23 Aug 2003, C Lund wrote:

> You mean @class Class in the *header* file, right? Because that way it
> works.

Uh, yeah, that's what I meant. :P

> > This last one is important. It's how you avoid circular #imports and
> > everybody goes home happy.

>
> I am anyway. Thanks. B)

Glad to hear it.

--
"From now on, we live in a world where man has walked on the moon.
And it's not a miracle, we just decided to go." -- Jim Lovell

Mike Ash - <http://www.mikeash.com/>, <mailto:mail@mikeash.com>

[Mark Haase]

In article <clund-AF03E0.18383223082003@amstwist00.chello.com>,
C Lund <clund@NOSPAMnotam02.no> wrote:

> Well, I'll #import Vertex.h in Surface for now. That works for now
> anyway. Maybe I can avoid calling Surface methods from Vertex.

I think this is generally the best way to approach the problem. A clean
top-to-bottom class hierarchy ought (IMO, or at least in my experience)
not to need backwards references.

Ie. The car class knows the interface of the engine class, but not vice
versa.

If you mess up and find yourself need to reference an object that you
can't #include, then a quick hack is to just use an id. Luckily in Obj-C
you can send messages to objects even if they don't repond to that type
of message.

[matt neuburg]

In <mehaase-FEA559.10441824082003@netnews.upenn.edu> Mark Haase wrote:

> In article <clund-AF03E0.18383223082003@amstwist00.chello.com>,
> C Lund <clund@NOSPAMnotam02.no> wrote:
>

>> Well, I'll #import Vertex.h in Surface for now. That works for now
>> anyway. Maybe I can avoid calling Surface methods from Vertex.

>
> I think this is generally the best way to approach the problem. A
> clean top-to-bottom class hierarchy ought (IMO, or at least in my
> experience) not to need backwards references.

You're missing the point. The whole point of #import (as opposed to #
include) is that circularity is prevented for you automagically. m.

--
matt neuburg, phd = [email]matt@tidbits.com[/email], [url]http://www.tidbits.com/matt[/url]
REALbasic: The Definitive Guide! 2nd edition!
[url]http://www.amazon.com/exec/obidos/ASIN/0596001770/somethingsbymatt[/url]
Subscribe to TidBITS. It's free and smart.

[Michael Ash]

In article <20030824084300575-0700@news.la.sbcglobal.net>,
matt neuburg <matt@tidbits.com> wrote:

> In <mehaase-FEA559.10441824082003@netnews.upenn.edu> Mark Haase wrote:

> > In article <clund-AF03E0.18383223082003@amstwist00.chello.com>,
> > C Lund <clund@NOSPAMnotam02.no> wrote:
> >

> >> Well, I'll #import Vertex.h in Surface for now. That works for now
> >> anyway. Maybe I can avoid calling Surface methods from Vertex.

> >
> > I think this is generally the best way to approach the problem. A
> > clean top-to-bottom class hierarchy ought (IMO, or at least in my
> > experience) not to need backwards references.

>
> You're missing the point. The whole point of #import (as opposed to #
> include) is that circularity is prevented for you automagically. m.

No, that's exactly not it at all.

#import prevents double-includes, where you get a file twice and you get
a million errors because everything's declared again. #import most
definitely does not prevent circularity. All it does is check to see if
you've already #imported the file and, if you have, doesn't do it again.
But this will cause problems if you have circular #imports. If A.h
#imports B.h and B.h #imports A.h, things won't work. A.h #imports B.h,
ok, then B.h #imports A.h which will have no effect because A.h is
already there. But B.h needs A.h to function, so you get errors.

As I said, the way to handle this is to only #import things in your .h
files when absolutely necessary (when you're inheriting). Otherwise use
@class declarations in the .h file and #import in the .m file. This
avoids circularity and works properly in every case.

[matt neuburg]

In <mail-E5F865.10562324082003@localhost> Michael Ash wrote:

> In article <20030824084300575-0700@news.la.sbcglobal.net>,
> matt neuburg <matt@tidbits.com> wrote:
>

>> In <mehaase-FEA559.10441824082003@netnews.upenn.edu> Mark Haase
>> wrote:

>> > In article <clund-AF03E0.18383223082003@amstwist00.chello.com>,
>> > C Lund <clund@NOSPAMnotam02.no> wrote:
>> >
>> >> Well, I'll #import Vertex.h in Surface for now. That works for now
>> >> anyway. Maybe I can avoid calling Surface methods from Vertex.
>> >
>> > I think this is generally the best way to approach the problem. A
>> > clean top-to-bottom class hierarchy ought (IMO, or at least in my
>> > experience) not to need backwards references.

>>
>> You're missing the point. The whole point of #import (as opposed to #
>> include) is that circularity is prevented for you automagically. m.

>
> No, that's exactly not it at all.
>
> #import prevents double-includes, where you get a file twice and you
> get a million errors because everything's declared again. #import
> most definitely does not prevent circularity.

Really? Well, then, maybe *I've* been missing the point! :) I thought
the whole idea was that every .m file could just #include every .h file
without fear. It has always worked for me. (I never #import an .h file
in an .h file, though, unless it's the superclass.) m.

--
matt neuburg, phd = [email]matt@tidbits.com[/email], [url]http://www.tidbits.com/matt[/url]
REALbasic: The Definitive Guide! 2nd edition!
[url]http://www.amazon.com/exec/obidos/ASIN/0596001770/somethingsbymatt[/url]
Subscribe to TidBITS. It's free and smart.

[matt neuburg]

In <mail-25C855.12384824082003@localhost> Michael Ash wrote:

> Double-includes is something different from
> circularity, where A includes B and C, but B also includes C. This is
> what #import protects against.

Right, I see - if C is B's superclass that could happen easily. m.

--
matt neuburg, phd = [email]matt@tidbits.com[/email], [url]http://www.tidbits.com/matt[/url]
REALbasic: The Definitive Guide! 2nd edition!
[url]http://www.amazon.com/exec/obidos/ASIN/0596001770/somethingsbymatt[/url]
Subscribe to TidBITS. It's free and smart.