Cocoa methods that return CF objects

[Christiaan Hofman]

I know, and my question is hals indeed about these functions in  
CFBase.h (they're what I linked to). I am pretty sure that testing  
will tell you it will work. But what I'm asking for is confirmation  
from the docs. It's pretty important if you want to use CF callbacks  
in collections (which in fact is used in sample code, it';s just not  
documented that this sample code would even be valid). And I already  
filed a bug report.

Christiaan

On 4 Jul 2008, at 7:01 PM, Gary L. Wade wrote:

> I seriously doubt such a scheme would always work,

Why? I'd say the opposite, as the existing docs, mailing lists, and  
sample code strongly suggest it. E.g. there's sample code using CF  
collections for Cocoa objects, and CF callbacks use more of CFBase.h  
than just CFRelease/CFRetain (the only ones that are documented to  
work AFAICS).

> but there's a number of CFType-based APIs in, I believe, CFBase.h,  
> that should provide some basic information about a general-purpose  
> CFType-object, so try those on your NSObject objects and see what  
> they do.

Yes, that's one of the links I gave (it's described in the CFType doc).

> In the meantime, I'd suggest writing a bug for documentation  
> clarification for this particular need.

I did already do that.

> And, if you do find the generic toll-free bridging works, make sure  
> you test every new version of Mac OS X, especially the seeds that  
> come out.  Only you can say if this would be worth it, but that's  
> what you'll have to do to prevent any surprises showing up on your  
> customers' doorsteps.

And I shouldn't have to. I'd say it's a pretty basic and important  
part of toll-free bridging. It would make CF collections pretty much  
useless for use in toll-free bridging.

Christiaan

>
> Christiaan Hofman wrote:
>> On 4 Jul 2008, at 5:12 PM, Jon Gotow wrote:
>>> At 11:09 AM +0200 7/4/08, Christiaan Hofman wrote:
>>>> Yes, but also this document does tell me the relevant bit of what  
>>>> I'd want to know. I am pretty sure it's incomplete, as I'm sure  
>>>> any function accepting CFType (and that's more than CFRelease and  
>>>> CFRetain) can accept also any Cocoa object (NSObject). Otherwise  
>>>> the standard collection callbacks would break and, if I'm not  
>>>> mistaken, those are used by Cocoa's collection classes.
>>>
>>> In general, most of these classes are "toll-free bridged" - ie.  
>>> they may be substituted for one another, and release/CFRelease are  
>>> interchangeable (except when GC is on).  There are a few, however,  
>>> that aren't interchangeable, such as NSBundle/CFBundle (see http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Classes/NSBundle_Class/Reference/Reference.html) 
>>> . I believe the basics, such as retain/release will still work on  
>>> the *Bundle classes, but I don't assume I can truly treat a CFType  
>>> as an NSObject unless the docs say that they're "toll-free  
>>> bridged", in Apple's terminology.
>>>
>>> - Jon
>> I think you misunderstand. I'm not asking which specific  
>> *subclasses* are toll-free bridged, that's indeed answered in the  
>> link provided by mmalc. My quetsion is whether a *generic* NSObject  
>> is toll-free bridged to a *generic* CFType. In other words: can I  
>> pass *any* Cocoa object (NSObject or subclass instance) to a CF  
>> function accepting a CFType and v.v. can I send Cocoa instance  
>> methods defined for NSObject to *any* CFTypeRef? I already know for  
>> sure that I can apply CFRelease/CFRetain on any Cocoa object. But  
>> what about the rest of  CFType declared in <http://developer.apple.com/documentation/CoreFoundation/Reference/CFTypeRef/Reference/reference.html 
>> >?And what about everything in <http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Classes/NSObject_Class/Reference/Reference.html 
>> > and <http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Protocols/NSObject_Protocol/Reference/NSObject.html#//apple_ref/occ/intf/NSObject 
>> >? Christiaan
>> _______________________________________________
>> MacOSX-dev mailing list
>> MacOSX-dev at omnigroup.com
>> http://www.omnigroup.com/mailman/listinfo/macosx-dev
> _______________________________________________
> MacOSX-dev mailing list
> MacOSX-dev at omnigroup.com
> http://www.omnigroup.com/mailman/listinfo/macosx-dev