Низкоуровневая совместимость между версиями, Перевод «Release-to-Release Binary Compatibility in SOM» Опции

[OCTAGRAM]

Представляю свой перевод широко известного (в узких кругах, которые неплохо бы расширить) доклада

Forman I.R., Conner M.H., Danforth S.H., Raper L.K. Release-to-Release Binary Compatibility and the Correctness of Separate Compilation // OOPSLA ’95 Conference Proceedings. New York: ACM, 1995. P. 426–438. doi:10.1145/217838.217880

После того, как в 1995м доклад был представлен на конференции, двое из его авторов в 1998м выпустили ещё более широко известную книгу «Putting Metaclasses to Work» (DJVU, PDF, ZIP с Java-симуляцией), и этот доклад с небольшими изменениями составил одноимённую главу 11. Этой книгой вдохновлялся создатель Python, на что он явно указывает в истории развития языка. На эту книгу часто можно видеть ссылки при обсуждении метаклассов.

Но нужно понимать, что объектная модель с множественным наследованием и метаклассами — это всего лишь отблеск SOM, а начиналось всё с другого. С RRBC. Я перевожу это как «Низкоуровневая совместимость между версиями». Возможно, неуклюже, но лучше пока не придумал.

Интересующиеся могут найти разную связанную с темой информацию и средства разработки по адресу http://octagram.name/pub/somobjects/

Доклад состоит из 12 разделов, включает в себя 9 рисунков и 1 таблицу. Раздел «Полнота множества трансформаций (Completeness of a Set of Transformations)» остался без перевода. В этом разделе несколько страниц формальных манипуляций, а по сути ничего особенно нового.

Низкоуровневая совместимость между версиями
и
корректность раздельной компиляции
Release-to-Release Binary Compatibility
and the
Correctness of Separate Compilation

Айра Форман, Майкл Коннэр, Скотт Дэнфорт, Ларри Рэйпер
Ira R. Forman, Michael H. Conner, Scott H. Danforth, Larry K. Raper

IBM Object Technology Products
Перевод: Иван Левашев

Несмотря на ожидания, повторному использованию программного кода в объектно-ориентированном программировании всё ещё предстоит достичь своего полного потенциала. Мы обнаружили, что главным препятствием для переиспользования является неспособность развивать библиотеки классов без прерывания поддержки уже скомпилированных приложений. Корни этой проблемы — в том, что типичная объектно-ориентированная модель содержит элементы, не входящие в модель интерфейса компоновщика. Следовательно, объектно-ориентированная модель должна быть разработана таким образом, чтобы трансформации библиотеки классов, которые в теории не должны приводить к неработоспособности уже скомпилированные приложения, и на практике тоже не делали этого. Это приводит нас (в заключении доклада) к новым критериям корректности раздельной компиляции для всех систем программирования.

Модель системных объектов (System Object Model, SOM) создана быть таковой. Следующая секция даёт обзор SOM, после которого мы вернёмся к проблеме написания и поддержке совместимых на низком уровне библиотек классов. Этот доклад представляет решение этой проблемы, воплощённое в SOM.

Оглавление

• Модель SOM
• Проблема совместимости библиотек
• Определение низкоуровневой совместимости между версиями
• Процедурное программирование
• Объектно-ориентированное программирование
• Когда классы — это полноценные объекты
• Как произведённые метаклассы помогают скомпилированным библиотекам
• Сравнение поддержки в различных объектных моделях
• Практика
• Полнота множества трансформаций
• Заключение
• Благодарности

• Послесловие от переводчика

[OCTAGRAM]

Сравнение поддержки в различных объектных моделях

Теперь, при выборе системы разработки, в которой будут создаваться скомпилированные библиотеки, нужно учесть, какие трансформации поддерживаются. Таблица 1 даёт сравнение для нескольких объектных моделей¹. Компиляторы Smalltalk и C++ — обычные, в то время, как Delta/C++ относится к компилятору C++ от Silicon Graphics, а OBI относится к исследовательской работе Sun Microsystems.

В таблице 1 √ значит, что трансформация поддерживается, а X — что нет. В случаях, когда трансформация не имеет смысла применительно к этой технологии, в таблице 1 находится «n/a».

Таблица 1. Сравнение поддержки скомпилированных библиотек классов


¹ Мы исключили Microsoft COM, поскольку это интерфейсная, а не объектная модель, и её ABI не позволяет наследование между библиотекой и приложением. Если применить нашу технику анализа к COM, можно увидеть, что она поддерживает только Трансформации 0, 1, 3, 4, что ставит её в категорию процедурного программирования, а не объектно-ориентированного.
^a Трансформация поддерживается для функций в скомпилированном ЛИСП, но не в обобщённых методах в CLOS.
^b Из-за перегрузки методов в C++, в этой ячейке формально получается X, так как добавление нового параметра определяет новый метод. Может показаться, что это не проблема, так как перегрузка позволяет множеству методов иметь одинаковое имя. Однако, в связи с этим ответ для процедур отличается от методов.
^c Однако, SOM поддерживает процедуры и методы, у которых определено переменное количество аргументов.
^d В компилируемом Smalltalk добавление полей требует перекомпиляции приложений.
^e Текущие реализации Java не поддерживают такое, но новые спецификации ясно требуют, чтобы все наши трансформации поддерживались.
^f Следует заметить, что OBI — это исследовательский проект, имеющий дополнительную цель в поддержке множественных версий класса.
^g Поскольку это подход C++, нужно удостовериться, что непубличные элементы не были сделаны видимыми через указание дружбы.
^h Objective-C поддерживает интерфейс прямого доступа к полям, тем самым делая в этом поле X. Брэд Кокс сообщил нам, что мудрые разработчики на Objective-C не пользуются этим средством (и тем самым ставят в этой ячейке √).

Однако, ни одна из этих технологий (включая SOM) не поддерживает Трансформацию 2. Это не препятствует развитию библиотек классов, потому что можно определить новый метод (с новым именем) с расширенной сигнатурой, в то время как прежний метод остаётся. Так, уже скомпилированные приложения выполняются как ожидается, а новые приложения используют новый метод.

Наша презентация была неформальной; например, мы не определили критерии для полного множества трансформаций, которые сохраняют совместимость (впрочем, и само сохранение совместимости не было формально определено). Обычно неполнота трансформаций влечёт другие недостатки. Но это не коснулось проблемы развития библиотек классов. Ясно, что SOM не полон, так как Трансформация 2 не поддерживается. Но, как было указано выше, это не серьёзное препятствие для развития библиотеки классов.