Re: CoreBase toll-free bridging

[Maxthon Chan]

However this is the Apple approach. Can we just think out of the box and 
maintain just API interoperability?

As I said, Apple used Core Foundation to serve both Cocoa and Carbon 
simultaneously, which is asking for a C API (Cocoa was in Objective-C and 
Carbon was C++, and there wasn't a good implementation of Objective-C++ then to 
allow implementing Carbon or Cocoa on top of each other, thus a C API is called 
for and Core Foundation is born. Before Cocoa, in NeXTSTEP ages, the NeXTSTEP 
libraries sits directly on libobjc and libc, just like current GNUstep.) So 
once again, it is okay for us to directly implement the entire CoreBase on top 
of Base? Not to say that this will make CoreBase code more portable as it no 
longer rely on the internal structure of the Objective-C runtime (To the extent 
that one can even port CoreBase back to OS X if any CoreBase extras is called 
for on an OS X app).

And just another idea, given that clang is now powerful enough, it is actually 
possible for us to implement Carbon in Objective-C++ based directly on 
Foundation (or Base).

在 2013-3-27，上午4:01，Luboš Doležel <address@hidden> 写道：

> Hi again,
> 
> I was investigating what approach Apple took in solving a problem with 
> calling CF functions on ObjC objects, which return an autoreleased object in 
> ObjC, but clearly shouldn't do so when using the CF call.
> 
> For instance, you have to release the result of CFTimeZoneCopyLocalizedName() 
> yourself, but you mustn't do that with [NSTimeZone localizedName:locale:], 
> since that will be autoreleased.
> 
> An ordinary CF_OBJC_FUNCDISPATCH from the former to the latter therefore 
> doesn't work correctly "out of box". Apple's source code showed no solution 
> at all, but still on OS X it seemed to work correctly...
> 
> So I took my disassembler again and voilá! The source code released by Apple 
> under the 10.8 section *doesn't match* the OS X 10.8 binares. In CFTimeZone's 
> case it doesn't match it at all.
> 
> CFTimeZone on OS X is *entirely* built on top of NSTimeZone.
> 
> CFTimeZoneCopyLocalizedName() actually does something like this:
> 
> =====
> _CFAutoreleasePoolPush();
> NSString* retval = [(NSTimeZone*)tzSelf localizedName: arg1
>                                               locale: arg2];
> 
> CFRetain(retval);
> _CFAutoreleasePoolPop();
> 
> return retval;
> =====
> 
> Which explains why it doesn't exhibit the above described problem as one 
> would expect from their source code.
> 
> So Chan, you were partially right. But I've checked other types and it seems 
> it is the case only in CFTimeZone.
> 
> -- 
> Luboš Doležel
>