[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Sat, 24 Oct 2009 10:10:52 +0100
I've done quite a bit of work with the source of Apple's CFLite
(working with OpenCFLite, and as the basis of my Foundation clone
PureFoundation) so I thought I'd just chime in here.
On 23 Oct 2009, at 22:34, David Chisnall wrote:
With regard to the CFTypeID, this should be the address of the class
structure. For those unfamiliar with how CoreFoundation works:
Each of the CF classes has an isa pointer, just like an Objective-C
object. Unlike Objective-C objects, this is set to a value below
64KB, which is guaranteed not to be the address of a real class.
This number is the CFTypeID, which is a
Sorry, but this is incorrect. If a CF type is bridged to obj-C/
Foundation, then the ISA operates as in obj-C. If it is not bridged,
or (as in CFLite) obj-C/Foundation classes are absent, this is NULL.
The actual CFTypeID is stored in the block of header data which
follows the ISA, and so is still present even if the ISA is set up as
Under Apple's CoreFoundation/Foundation, the bridged classes are
private end-of-tree subclasses. eg. for NSString, the class is
NSCFString (it runs NSString -> NSMutableString -> NSCFString, and
whether the NSCFString is mutable or not depends on how it was
created, and is flagged internally). Their ivars start with the ISA
and then there follows the block of CF-specific fields which I don't
believe are mapped/accessible as ivars. If you look at the CFLite
source, this is CFRuntimeBase structure defined in CFRuntime.h.
Which is all besides the point, because you're not looking to exactly
clone Apple's CF here. So, Stef, your best approach is definitely, as
1) Define Objective-C classes that implement the CF types (many of
these already exist in GNUstep).
2) Write wrapper functions that call the ObjC methods.
3) Return the address of the class as the isa pointer.
You may also want to implement Apple's super-secret -
(CFTypeID)_cfTypeID method, which returns the CFTypeID of bridged