On Tue, Jul 15, 2008 at 4:39 PM, <
email@hidden> wrote:
-------------- Original message ----------------------
From: Sebastian Nowicki <
email@hidden>
> I also can't think of a way to use the typedef'd C structs and
> enums from the library in the header file without including the
> library header file. This is tricky indeed. If only I could see how
> Apple did it with OpenGL, etc :P.
If however the framework tries to completely hide/greatly simplify use of the library, perhaps you should try to think of how to eliminate the need for exposing the low level C structs and constants. For example, does the user really need to know all the enums? Or could you present a simpler set of choices and resolve the particulars inside you wrapper methods? A good concrete example for what I'm talking about is NSImage.
A one-to-one mapping of framework methods/constants/datastructures is probably not a good idea. Let users pass in NSArrays, NSDictionaries or some defines and do the necessary translation to enums/ C structs etc inside your class. That way, you don't need to include the library headers in your class header. You can restrict that stuff to the implementation file's #import "lib.h". The header would just have standard objective C objects.
This is pretty much what I'm trying to do. The framework won't overly simplify the usage of the library - there isn't really much to simplify. I do add some things which are a bit higher level. The main reason why I'm doing this is to just make it easier for me to later use the library in an application. Since I want to use Cocoa for the GUI, it's much easier to use NSArray, NSString, etc, and the framework, for the most part, currently offers this. Additionally it's just much cleaner to have it as OOP instead of passing around pointers and such.
There are very few places where I actually return an enum from the C library. As previously mentioned, I simple don't know how to handle this, and it would be returning an enum either way (I'd just need an "alias"). I mostly use the structs from the library internally, ie., as instance variables. It would otherwise be impossible for me to do anything in the class :P. For instance if there's a struct apple_t, I make a class Apple, and internally the class must store the apple_t struct somewhere. In order to define this variable I have to import the header from the library. e.g:
#include "applelib.h"
@interface Apple : NSObject
{
apple_t *apple;
}
@end
In this case, how would I hide apple_t? As far as I know I can't import and abstract it in the .m file, unless there's something like @class for typedefs, extern only works on variables. On rare occasions I also have methods which return an enum from the library (I also want to abstract this):
- (some_enum) doSomething;
Once again I don't know how to abstract the enum in the .m file and then use the abstracted enum (or whatever) in the header file.
There's also the issue of translating the structs into objects within other classes. This can occur when methods relating to one struct would return an array of another struct, or something. Then I have to initialize an instance of a class with the struct. Currently I use something like this:
- (id) initWithApple:apple_t *theApple
{
...
apple = theApple;
...
}
I really don't like that method of doing it, especially since the method is exposed, and since it initialises, I can't exactly use a category.
There might be a few places where I simply looked at the C library and translated it into OOP code, and I could have otherwise improved the code a bit, so I'll revise the code. This would still not resolve the issue I am having with including the header file though.
Sorry if there's something fundamental I'm missing. I'm still a student and quite new to both ObjC and C.