Проблемы, острая нехватка подробной документации и неточности в той, которая была – все это касалось не только Core Foundation, в моем случае самым тяжелым участком был IOKit – и всегда находились люди, готовые ответить на все вопросы – а со временем и я стал помогать другим. Это было здорово. Чем-то похоже на Stack Overflow, но… какое то неуловимо иное.

Мы все (относительно небольшое Mac’овское сообщество начала нулевых) мечтали о невообразимо прекрасном и сказочном времени когда мир, наконец, полюбит Apple, как и мы. Это произошло, очень скоро, у Apple теперь все в шоколаде – а что-то, что не выразить словами, ушло. Это было невероятное время, тревожное и необычное.

Забавно: в течении 20 лет Core Foundation я понимал, о чем идет речь, но впервые решил посмотреть – а как это словосочетания переводится на общегражданский русский. Вдруг у интуитивно понятного термина есть еще какой-то смысл?

Есть. Это “основной фонд”. Так оно и было, на самом деле. Core Foundation, и производные от неё библиотеки (Core Graphics, она же Quartz 2D]6 и другие) были и остаются основным фондом системы.

Они и в наши дни живее всех живых. Swift меняет их до неузнаваемости, и похоже, их ждет очередной звездный час, и снова нестерпимо хочется заглянуть туда, в это будущее…

Core Foundation – основы и принципы

Если называть вещи своими именами, не заморачиваясь по поводу неизбежной неточности “своих имен” и прочих вариантов аналогий, это аккуратно переписанный на чистом C (ANSI C, в основном) немаленький фрагмент Foundation Kit, одного из двух главных фреймворков NeXTSTEP/OPENSTEP, унаследованного сначала Rhapsody, затем YellowBox, и, наконец, как только все стало устаканиваться, ставшего частью Cocoa.

Перенос части Foundation в среду на чистом C потребовал пересмотра концепций и сути исходного комплекса и безжалостного отсечения всего, без чего можно было обойтись, на принципиальные ошибки и их исправление времени не было. На самом деле все писалось с нуля, целью были совместимость и, как ни странно, простота в использовании.

Роль классов в CF исполняют “непрозрачные типы”. С точки зрения пользователя CF, это ссылки (references) на типы данных с скрытой структурой. Спрятали? А вот и нет. Система еще только создавалась, изменений было не много, а ужасно много – и, как правило, все эти изменения были непредсказуемы. Сущность, взаимодействие с которой осуществляют специальные функции – удачный компромисс.

Данные этих непрозрачных типов называли объектами – по сути, они ими и были. Это были value-типы, если использовать терминологию Swift. Непрозрачные типы объединялись в иерархию, с базовым типом, для которого были определены базовые функции, доступные всем остальным “классам” иерархии. Роль базового типа исполнял CFType, для которого были определены функции CFRetain, CFRelease, CFEqual и некоторые другие.

В типах-наследниках все эти функции могли быть использованы, но обычно в каждом из них определялись и свои собственные, учитывающие особенности своих “клиентов”.

CFRetain и CFRelease аналогичны методам retain и release базового класса Cocoa, NSObject – это главные инструменты выделения и освобождения памяти для объектов. Принципы те же, что и в Cocoa, несколько упрощенные, основанные на подсчете ссылок на объект.

С 2012 в Cocoa ссылками и их подсчетом занимается ARC (Automatic Reference Counting), и пришедшие в любое из нынешних воплощений Cocoa с эзотерической практикой “retain/release/autorelease” незнакомы – а жаль. В наше время только научившийся точно и без долгих размышлений учитывать этот аспект реальности мог считаться освоившим Cocoa, а занимало усвоение этой эзотерики несколько месяцев. Наверное из-за стресса, остальное осваивалось легко, быстро и незаметно.

До CF ARC добрался через пару лет.

В Cocoa и в CF были (и есть) взаимно совместимые пары классов и непрозрачных типов, например, NSString и CFString, данные любого из этих типов могли быть преобразованы в данные связанного с ним родственными узами типа из другой библиотеки приведением типа (type casting). Структура данных в обоих типах была идентичная.

Исходный код написанный в Core Foundation отличался от аналогичного кода в Cocoa в разы большим числом букв. Core Graphics (Quartz) унаследовал эту особенность.

Продолжение следует