Itoa's approach to Foundation library

Let me put it straight -- Itoa gives up possibility to inherit from some Foundation classes in favor of compatible implementation based on Apple's CoreFoundation.

Now for the explanation.

There are two approaches to implement CoreFoundation and Foundation libraries:

1. Apple's approach. Implement both CoreFoundation and Foundation libraries. Base small portion of Foundation classes on CF (e.g. NSString, NSNumber), implement toll-free bridging to wire up two libraries.
2. GNUStep/Cocotron's approach. Implement Foundation library only. Make CoreFoundation classes/functions to be simple wrappers around corresponding Foundation classes.

Both approaches allow you to:

1. Use CoreFoundation and Foundation classes interchangeably. I.e. you can cast NSString to CFString and vise versa.
2. Inherit from Foundation class and still enjoy #1. I.e. you can create your own subclass of NSString and still safely cast it to CFString.

Apple's approach is far more complex and involves creation of classes with duplicating functionality in both libraries not to mention carefully crafted callbacks from CF to Foundation to handle #2 above.

GNUStep/Cocotron's approach is more natural - you only have one implementation and don't worry about inheritance, bridging and such.

Since Itoa tries to be Apple-compatible as much is possible and Apple open-sourced only CoreFoundation library, Itoa takes third approach:

• Implement CoreFoundation library only. Make all corresponding NS classes to be simple bridged wrappers. Implement functionality required by NS classes in corresponding CF classes. Give up #2.

Well, actually there are things that can be done to allow #2 (basically one needs to properly size NS classes and implement CF->NS bridging for abstract NS class methods), but they are currently out of scope.

However, there is a catch -- Apple's CoreFoundation is a terrible mess for a newcomer. I'm sure Apple guys have no problem supporting and extending CF, but for person from outside it looks like a convoluted pile of #ifdefs, 100k+ files, private functionality, unclear dependencies and other fun stuff. To be actually able to use (and extend!) CoreFoundation it had to be refactored. And it was! In the next post I will introduce CleanCF, a greatly refactored CoreFoundation.