Re: Can one extend CoreFoundation using Obj-C?
Re: Can one extend CoreFoundation using Obj-C?
- Subject: Re: Can one extend CoreFoundation using Obj-C?
- From: Brian Cave <email@hidden>
- Date: Sun, 29 Jul 2001 22:34:55 -0500
On Sunday, July 29, 2001, at 04:10 PM, Brian Hill wrote:
On Sunday, July 29, 2001, at 01:20 PM, Brian Cave wrote:
I want to have a unique CFTypeID that my class exports that would be
unique in the same manner as these already are in the CoreFoundation
world, no better. And I want my class to be retainable / releaseable
using the CoreFoundation retain / release APIs. I do not desire any
more compatability than this.
I looked into this a while back, and even downloaded the portion of the
CF source in Darwin so I could see how it's done. Right now, it can't,
per se.
There are several limitations to the CF itself (a fairly restrictive
limit on the global number of CF types allowed in a single process --
255 -- for example), and the internal API that you'd need to use (which
you could dig out of Darwin) is very likely to change. In fact, I'd
almost put money on it having changed in 10.1.
However, someone on this list (I forget who, sorry) had the excellent
suggestion of wrapping my class around a CFData. Create some accessors
to store the class' private instance data (ie., a struct) in the CFData.
What I ended up doing in the end was to just create a separate set of
CF functions for my own class' use that paralleled the standard CF ones
(ie., CFXRetain instead of CFRetain). I also created my own set of
collection-handling functions for CFDictionaries and CFArrays that did
the right thing with both my own CF-like types and standard CF types.
Brian
I have now proved that this can be done and it works. Just a few
limitations. Here is what I did and what I can't do.
Create a new Obj-C class inheriting off of NSObject (or I imagine you
could do this off of any NS object).
Design and build your class as normal (instance vars, functions, etc).
Then create your CF style interface functions as C APIs. The guts of
these are glue code to call the Objc-C class you made. Note, all
functions that you want to be external must be declared here. Also,
any vars you want access to in the outside world will need Get and/or
Set accessor glue functions as C APIs.
Put the prototypes for the C APIs into a standard C header that first
includes at least CFBase.h or probably better CoreFoundation.h. This
must include appropriate typedefs for mutable and/or immutable (if you
need such a difference anyway), at least one CFCreate variant for your
specific class, and you should also provide a CFMyTypeGetID() call for
consistency sake. Unfortunately, CFAllocatorRefs can't be used here,
but I am going to provide them as place holders (for consistency sake)
and simply ignore the value. You could hook them up to NSZone, but
only the normal default allocator works. kCFAllocatorMalloc or
kCFAllocatorSystemDefault will generate an EXC_BAD_ACCESS error.
CFRetain(), CFRelease(), CFGetRetainCount() so far work perfectly.
CFGetTypeID() always seems to return 1. This value appears to be an
internal CFType type (according to the public source code for
CoreFoundation). I can override it by defining the _cfTypeID static
member and having it return a different value, but I have *not* yet
determined if this is safe. Nor can I determine what would be a
non-conflicting number to return (other than the current implementation
of this number in CF suggest that negative numbers would never be
generated by it). Returning a negative number does not seem to fail the
CF functions I have tested at least so far.
I imagine (but have not tested) that CFEqual and CFHash should work
through the normal Obj-C equivalent member functions. That is the way
that CF works through Obj-C according to both the CF source code and my
own tests.
So far my tests have been from a modified Foundation tool project
template. I am going to test this via a framework (Mach-O obviously)
which is my ultimate goal. I figure CFM can always use CFBundle to load
and execute it (that is if I ever need to use these APIs from CFM).
HTH,
brian
_____________________________________________________
Brian Cave <
mailto:email@hidden>