• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Building a C library Objective-C wrapper framework
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Building a C library Objective-C wrapper framework


  • Subject: Re: Building a C library Objective-C wrapper framework
  • From: email@hidden
  • Date: Tue, 15 Jul 2008 08:39:54 +0000

 -------------- 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.

Have you thought of exactly how your framework will improve/simplify use of the library? If the users of your framework need to know all the data structures and enums in the library in addition to the added overhead of your framework, there's not much to recommend a framework.

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.

NSImage can open many different types of files, tiffs, jpegs, eps's etc but the user doesn't need to know or care about a any of the nitty gritty stuff, they just pass a path or url and get a nice simple object to work with. They don't need to know how each format stores sizing or color information, the NSImage class presents a nice consistent -(NSSize) size method. Could you, with a little thinking, do a similar simplification for users of your framework?

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.
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Follow-Ups:
    • Re: Building a C library Objective-C wrapper framework
      • From: Sebastian <email@hidden>
  • Prev by Date: Re: Resolving conflicting typedefs uint32
  • Next by Date: Re: Xcode project has lost track of file modification
  • Previous by thread: Re: Building a C library Objective-C wrapper framework
  • Next by thread: Re: Building a C library Objective-C wrapper framework
  • Index(es):
    • Date
    • Thread