Cocoa methods that return CF objects

[Christiaan Hofman]

On 5 Jul 2008, at 4:19 PM, Jim Correia wrote:

> On Jul 4, 2008, at 10:44 PM, Jon Gotow wrote:
>
>> At 2:49 AM +0200 7/5/08, Julien Jalon wrote:
>>> Any CFType instance is toll free bridged to an instance of some  
>>> NSObject subclass and any NSObject or subclass instance can be  
>>> used as a CFType instance. This is part of Core Foundation design  
>>> concepts. While the documentation could be clearer on this subject.
>>
>> This applies to _any_ CFType instance?  I've been "playing it safe"  
>> by only assuming that objects explicitly documented as being toll- 
>> free bridged were safe to treat as both a CFType or NSObject  
>> subclass (that was what I was saying in my first reply - if a class  
>> is documented as being toll-free bridged, the implication is that - 
>> release and CFRelease will both work without issue, but I don't  
>> assume that if there are distinct, non-miscible implementations,  
>> like with NSBundle and CFBundle).
>
> CFRetain/CFRelease *must* work correctly with any NSObject for toll- 
> free bridging of collections to work.
>

Indeed, that's what I've been saying several times now, and why I  
think this is not just an academic question, but an essential part of  
info if you want to use Carbon+Cocoa.

> Consider you are passed an NSMutableArray to which you are going to  
> add objects. Is it really an NSMutableArray, or is a a  
> CFMutableArrayRef that someone

...and that someone could be Foundation in its implementation of - 
[NSMutableArray init] (implementation detail, I don't really care)...

> has cast to an NSMutableArray because of toll-free bridging? You  
> don't know, and you shouldn't have to care; you just add objects to  
> it.
>
> So the default callback block used by the implementation needs to  
> retain/release the objects as appropriate, and due to the above, it  
> needs to be able to handle both CFTypeRefs and NSObjects.
>
> Jim

And IMHO that should also imply that *any* function in CFBase.h  
accepts Cocoa objects, considering that the default callbacks for CF  
collections use almost all of it, not just CFRetain/CFRelease (e.g.  
CFHash, CFEqual, CFCopyDescription, ..., and it doesn't make any sense  
to draw the line somewhere in between).

And v.v., if Cocoa correctly identifies a generic CFTypeRef as an  
NSCFType and NSCFType is a subclass of NSObject (which both are true  
according to simple tests, at least on 10.5.x but probably on all of  
10.x.x), then CFType and NSObject are indeed toll-free bridged. QED.

Christiaan