macOS Datastructure / Class design in Cocoa

[gekko513]

Even though I've been dabbling in Cocoa for one and a half year now, I haven't gotten entirely comfortable with some of the design aspects of the Objective C / Cocoa / Xcode combo.

What kind of files do I create to add new types and c functions for making them, like NSPoint and NSMakePoint(x, y).

Lets say I want a type

typedef struct {
  float a;
  float x;
  float y;
  float z;
} ASRotation;

ASMakeRotation(float a, float x, float y, float z);

The definitions can't be in the .h file of an Objective C class, because you're not supposed to import the .h files of another Objective C class in the .h file of a class.

Do I use New File -> BSD -> C File? Or something else?

 

[mrichmon]

Do I use New File -> BSD -> C File? Or something else?

Yes, you use New File->BSD->C File and then give the file a .h name.
Import the file where you need it using #import "foo.h".

 

[gekko513]

Yes, you use New File->BSD->C File and then give the file a .h name.
Import the file where you need it using #import "foo.h".

I went the BSD->C File way first. I need to implement the function somewhere too, so I had both a foo.c and a foo.h. I ran into trouble because when the when foo.c was compiled, none of the regular Cocoa headers where included, obviously, and that made it difficult to accomplish what I wanted.

I decided to try the usual New File->Cocoa->Objective C class for a foo.m and foo.h combo and then just removed the @interface and @implementation sections, and that seems to work just the way I want.

Are there any reasons that I have missed to why I shouldn't do it this way?

 

[HiRez]

I usually put such C struct/typedefs in the prefix file, which will automatically be available to all your Obj-C files. I don't know if that's good practice, but it seems to work. I also have the prefix file import all the large APIs I'm using (Cocoa, CoreAudio, QuickTime, or whatever), so I only have to do it once.

 

[gekko513]

I usually put such C struct/typedefs in the prefix file, which will automatically be available to all your Obj-C files. I don't know if that's good practice, but it seems to work. I also have the prefix file import all the large APIs I'm using (Cocoa, CoreAudio, QuickTime, or whatever), so I only have to do it once.

How would you solve the issue of defining and declare functions for creating those structs, such as the ASMakeRotation function that I mentioned?

 

[savar]

I went the BSD->C File way first. I need to implement the function somewhere too, so I had both a foo.c and a foo.h. I ran into trouble because when the when foo.c was compiled, none of the regular Cocoa headers where included, obviously, and that made it difficult to accomplish what I wanted.

I decided to try the usual New File->Cocoa->Objective C class for a foo.m and foo.h combo and then just removed the @interface and @implementation sections, and that seems to work just the way I want.

Are there any reasons that I have missed to why I shouldn't do it this way?

It's not like the template you use affects how the file is read. All that matters is the extension, and in either case you've created a .h file. If you want access to Cocoa headers, then just include them. But there's nothing wrong with you've done.