Монстр по имени Mac OS X

В 1999 году Mac OS X не вышла. Вмешались непредвиденные обстоятельства, кроме того, пришлось переписывать графический движок, а в индустрии уже посмеивались над Apple, взвалившей на свои плечи столько невыполнимых задач сразу.

Началось непредвиденное обстоятельство вполне невинно, с обсуждения взаимодействия приложений для Carbon с приложениями для Cocoa. Вообще-то, это взаимодействие было не то чтобы невозможно. Никаких мистических барьеров между Objective-C и C, о которых в те времена писали некоторые авторы, никогда не было.

Objective-C отлично работал даже с C++. Точнее, с C++ работал его вариант Objective-C++, подробности ниже.

Барьеров не было, но абстракции у каждой из частей системы были очень разными: при передаче информации из одной части в другую (а ситуации, когда в одной из частей есть библиотека, необходимая программисту, который работает в другой – случай рядовой и обыденный) приходилось тратить непозволительно много времени на перевод, и даже на изучение “иностороннего” языка.

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

Решили написать такую библиотеку сами, заранее. Назвали её Core Foundation. Если вы имели дело с программированием для Mac’ов и/или iOS, вы слышали про неё, и некоторые её производные (Core Graphics, например). И, с некоторого момента, она зажила своей собственной жизнью, и выросла в нечто значительно большее, чем тонкий пограничный слой объектов и кода…

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

Core Foundation

Дано: есть две части одной и той же операционной системы, в каждой из них есть, или со временем будут, библиотеки интересные для противоположной части системы. Каждая их частей организует и представляет данные по своему. Одна из них делает это не просто по своему, но еще и множеством разных способов, на разных языках (в основном на C++ и на C, но не только).

Технические требования к связующим обе части библиотекам определились легко.

В качестве языка реализации связующих библиотек был выбран C, который понятен без перевода по обе стороны границы. Если грамотно учесть особенности реализации C в C++, а на Apple неграмотные инженеры если и работают, то не инженерами (менеджерами?), все будет нормально работать.

С другой стороны, для сильно объектно-ориентированной части операционной системы, было бы логично обмениваться с противоположной стороной “объектами”. C не считается объектно-ориентированным языком, но…

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

Мне иногда (когда я жил в чистом C) очень хотелось учудить что-то такое… Но увы.

На Apple спроектировали псевдо-объектно-ориентированную систему, в которой роль объектов выполняли структуры с скрытым содержанием, с каждым из типов которых был связан свой набор функций и процедур. Если вы не понимаете о чем речь, не волнуйтесь.

Постараюсь не залезать во всю эту механику слишком глубоко. Извините, коллеги – если кто-то из вас случайно забредет в этот текст.

Чтобы уменьшить число неопределенностей, набор и принципы структур данных в Core Foundation скопировали (довольно близко к тексту) в Cocoa. Добавили в свои библиотеки то, чего в Cocoa никогда не было (CFTree, например).

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

На той стороне, в Cocoa, брат-программист преобразует этот универсальный объект в объект какого-то класса… Бум – опять нехорошо. Со стороны Cocoa, сильная сторона которого – высокая скорость программирования, работа с таким объектами слишком трудоемка…

И тогда какой-то сумасшедший придумал “посадить” Cocoa на этот самый приграничный слой, и заставить самые используемые объекты Core Foundation превращаться, по воле программиста, из объекта Cocoa в объект Core Foundation и обратно…

А какой-то другой сумасшедший решил, что это именно то, что надо – и что на такое не жалко потратить кучу лишнего времени… Этого кого-то звали Эви. Джобс, который во все совал свой нос, думал над этим предложением несколько дней (проект, пока еще почти нелегальный) уже был в работе, под прикрытием Эви, и… согласился.

Он не был технарем, но чутье на красивые решения у него было.

Objective-C++

Objective-C++ – гибридный язык, разработан (случайно) на NeXT Software, незадолго до поглощения ей Apple (или наоборот).

Objective-C++ никто специально не проектировал. Для забытых уже целей, одному из инженеров NeXT потребовался компилятор компиляторов (типа yacc или bison).

Но, либо для его задачи в этих простых и надежных “кк” чего-то не хватало, либо его мучила любознательность, вместо них он решил использовать компилятор компиляторов “на стероидах” (никак не могу вспомнить, как он назывался – а ведь и я пару месяцев его помучал, из любопытства, лет 20 назад).

И, в качестве упражнения, он написал компилятор языка, объединяющего в себе C++ и Objective-C. И C.

Компилятор был невероятно медлительным, но дело свое делал хорошо, и его включили в инструментарий разработчика NeXT, который перешел в Project Builder Mac OS X.

Получился язык, незаменимый при импорте в Cocoa кода, написанного на C++.

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