Mac OS X: Основной фонд

Возможно, Mac OS X “взлетела бы” и без Core Foundation – но не факт. Ничего подобного этому объектно-ориентированному слою на чистом C я нигде не видел. Даже если и есть что-то подобное в мире, CF достоен отдельного рассмотрения.

Когда этот слой был спроектирован и реализован, мне неизвестно – я впервые столкнулся с ним в начале 2001 года, когда подробной и внятной “фирменной” документации еще не было, разработка Core Foundation продолжалась, багов в нем было немеряно – а задачи по переносу в Carbon приложения размером почти в миллион строк стала жизненно важной.

Наверное, в воскрешении и возрождении Apple больше всего виновато её руководство и её инженеры – но сотни сторонних разработчиков, переносивших свои программы в этот новый неизведанный мир тоже причастны к этому.

Это шестая часть серии о превращении Apple в NeXT Apple. Предыдущие части:

И мы приложили к этому руку…

Конкуренция и соперничество никуда не делись, в Carbon переносили свои продукты злые и непримиримые конкуренты, но проблемы и непонятки были общие, и люди делились тем, что им удалось выяснить, иногда ценой проб и ошибок. И делали это (скрывая свои имена псевдонимами и не называя место работы) от всего сердца, понимая что успех платформы нужен им всем.

Среда менялась, информация устаревала очень быстро – особенно “хаки”. Со временем, на форумах (их было несколько) инженеры Apple стали сообщать о своей принадлежности к Apple, видимо Стив решил что это нужно и важно, и официально снял запрет. Многое из того, что сообщалось на этих форумах было бы коммерческой тайной, если бы не тяжесть ситуации. Все еще висело на тоненьком волоске.

Проблемы, острая нехватка подробной документации и неточности в той, которая была – все это касалось не только 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) унаследовал эту особенность.

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