У 1999 році Mac OS X не вийшла. Втрутилися непередбачені обставини, крім того, довелося переписувати графічний движок, а в індустрії вже посміювалися над Apple, яка звалила на свої плечі стільки нездійсненних завдань відразу.
Почалася непередбачена обставина цілком невинно, з обговорення взаємодії додатків для Carbon з додатками для Cocoa. Взагалі-то, ця взаємодія була не те щоб неможливо. Ніяких містичних бар'єрів між Objective-C і C, про які в ті часи писали деякі автори, ніколи не було.
Objective-C відмінно працював навіть з C++. Точніше, з C++ працював його варіант Objective-C + +, подробиці нижче.
Бар'єрів не було, але абстракції у кожної з частин системи були дуже різними: при передачі інформації з однієї частини в іншу (а ситуації, коли в одній з частин є бібліотека, необхідна програмісту, який працює в іншій - випадок рядовий і буденний) доводилося витрачати недозволено багато часу на переклад, і навіть на вивчення « оронньої» мови.
Розумний програміст, поставлений у такі умови не вперше, виділив би особливо часті та каламутні випадки спілкування, і написав би власну бібліотеку для їх спрощення та уніфікації. Уявіть собі: замість того, щоб збільшувати цінність операційної системи унікальними програмними продуктами, сотням програмістів доведеться або «перекладати» дані, що передаються, або писати свої бібліотеки для цього...
Вирішили написати таку бібліотеку самі, заздалегідь. Назвали її Core Foundation. Якщо ви мали справу з програмуванням для Мас'ів і/або iOS, ви чули про неї, і деякі її похідні (Core Graphics, наприклад). І, з деякого моменту, вона зажила своїм власним життям, і виросла в щось значно більше, ніж тонкий прикордонний шар об'єктів і коду...
Це п'ята частина серії про перетворення Apple на NeXT Apple. Попередні частини:
- NeXT Apple.
- Apple вибирає шлях.
- Кам'яновугільний період (Карбон) в історії 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. І С.
Компілятор був неймовірно повільним, але справу свою робив добре, і його включили в інструментарій розробника NeXT, який перейшов в Project Builder Mac OS X.
Вийшла мова, незамінна при імпорті в Cocoa коду, написаного на C++.
Продовження слід