2

To me it doesn't seem like it. Of course I don't have sources of Foundation, but in case of GNUStep, take this example.

They have a NSArray code like this https://github.com/gnustep/libs-base/blob/master/Source/NSArray.m

Nowhere in the source do they refer to CFArray.

https://github.com/gnustep/libs-corebase/blob/master/Source/CFArray.c

Same goes for all CF counterparts. Why?

Novellizator
  • 13,633
  • 9
  • 43
  • 65

2 Answers2

2

GNUstep's Foundation classes do not use Core Foundation. GNUstep started out as a free, open source implementation of the OpenStep specificiation. The Foundation and AppKit classes are both derived from the OpenStep specification. While GNUstep's goal is to catch up with current versions of Cocoa (according to GNUstep's Wiki it pledges compatibility with Mac OS X Tiger, and some classes and methods from newer versions of macOS have been added to GNUstep), my understanding is GNUstep does not have any Core Foundation dependencies. I found an interesting 2005 mailing list post discussing why GNUstep does not use Core Foundation.

When Apple announced its Mac OS X strategy in 1998, it provided two APIs for developers: Cocoa, which was an updated version of the Foundation and AppKit libraries, and Carbon, which were C APIs derived from the classic Macintosh Toolbox that were updated to be suitable in an operating system with preemptive multitasking and protected memory. Both Carbon and Cocoa were built on top of Core Foundation, which provided a common bridge for both APIs. Carbon and Cocoa were equal peers in Mac OS X, with neither API being favored over the other.

So, in a nutshell, Core Foundation was added to Mac OS X as a compatibility bridge between Cocoa and Carbon. But GNUstep is essentially modern OpenStep, and OpenStep never had Core Foundation, and thus GNUstep's Foundation does not use Core Foundation.

linguae
  • 85
  • 5
1

GNUStep is not the same as Apple's Foundation. I don't know much about how GNUStep is implemented, but in Apple's Foundation, NS and CF counterparts are very closely linked indeed. As you say, we don't have the source for Foundation, but there are still many ways to detect integration between the two. One really easy-to-spot one is just to inspect the class of many Foundation objects:

NSMutableString *string = @"Foo".mutableCopy;
NSLog(@"%@", NSStringFromClass(string.class));

This little program outputs __NSCFString, a clue that CFString's implementation is indeed being used under the hood. Specifically, NSString and CFString (as well as NSArray and CFArray, NSDictionary and CFDictionary, and many other Foundation and CF types) are toll-free bridged—this means that their internal structures are designed to be exactly the same, such that you can actually convert one to the other with a simple typecast, with no expensive conversion process. So NSArray doesn't just use CFArray, it actually is a CFArray.

Of course, since it's allowed to make your own private subclasses of classes like NSString, NSArray, et al., this means that for the bridging to work, the CF functions need to be able to handle the case where what looks like a CF object is actually an Objective-C subclass, and use the Objective-C implementation if it is. And for that reason, CoreFoundation objects, which we do have much of the sources to, do actually make many references to their NS equivalents, such as the CFArray source linked below, which contains references to NSArray.

https://opensource.apple.com/source/CF/CF-1153.18/CFArray.c.auto.html

Charles Srstka
  • 16,665
  • 3
  • 34
  • 60
  • The references to `NSArray` are in `CF_OBJC_FUNCDISPATCHV`, what does `CF_OBJC_FUNCDISPATCHV` do? – Willeke Sep 10 '17 at 22:04
  • @Willeke Well, the source to the version in the actual Apple frameworks isn't available (there's a "lite" version for building on Linux and other platforms where Objective-C integration isn't important that defines the glue macros as no-ops, but we don't have the source to the "real" one), so it's not possible to say with 100% certainty. However, it seems like a decent guess that they probably check whether the object is a custom Objective-C subclass, call the Objective-C method and early-return if it is, and continue to the normal implementation if it isn't. – Charles Srstka Sep 10 '17 at 22:18