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 <lu...@dolezel.info> 写道: > 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 > _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev