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

В качестве языка реализации связующих библиотек был выбран 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++.

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