Низкоуровневая совместимость между версиями, Перевод «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]

Проблема совместимости библиотек

В SOM существует явное разграничение между программным интерфейсом (Application Programming Interface, API) и низкоуровневым (Application Binary Interface, ABI). API — это интерфейс, которым пользуется разработчик, а ABI — это набор соглашений, от которых зависит исполнение программ. Совместимость на уровне API значит, что приложения могут быть успешно перекомпилированы; совместимость на уровне ABI значит, что скомпилированные приложения продолжают успешно работать.

Давайте рассмотрим затруднение поставщика программного кода, который продаёт программную библиотеку; покупатели поставщика библиотеки используют библиотеку для разработки приложений. Поставщик библиотеки даёт покупателям описание API библиотеки (например, заголовочные файлы или OMG IDL) и скомпилированную библиотеку в форме динамически компонуемой библиотеки (Dynamically Linked Library, DLL). Интерфейс (скомпилированной) DLL называется ABI. Преимущество использования DLL (и для поставщика библиотеки, и для создателя приложения) — в том, что несколько приложений могут выполняться с одной копией DLL, что значительно уменьшает требования к оперативной памяти и улучшает время отклика. Проблемы начинаются, когда поставщик библиотеки пытается развивать библиотеку. Поставщик библиотеки должен поддерживать низкоуровневую совместимость между версиями, потому что создатель приложения не может перекомпилировать уже разосланные копии приложения.

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

С прагматичной точки зрения, версия библиотеки совместима на низком уровне, если все приложения, использующие библиотеку, продолжают работать. В отсутствие точной спецификации и для приложения, и для библиотеки, это субъективное суждение. Например, можно устранить дефект в библиотеке и обнаружить, что разработчики приложений посчитали его особенностью поведения.

Теперь немного абстракций; покажем на примере, как C++ не справляется с поддержкой низкоуровневой совместимости между версиями. На рисунке 2 изображена ситуация, при которой от класса X (из библиотеки классов) наследуется класс Y в приложении. С библиотекой версии 1.0 приложение работает великолепно; в частности, можно вызвать fmethod у iY, экземпляра класса Y. Теперь рассмотрим, что происходит, когда поставщик библиотеки делает на первый взгляд безвредное изменение, добавляя метод (hmethod) к классу X, который вызывается из fmethod. Теперь, поскольку приложение собрано с использованием старого определения библиотеки, в таблице методов Y указатель на gmethod ожидается во второй ячейке. Однако, когда у iY вызывается fmethod, он впоследствии пытается вызвать hmethod, который в классе X находится во второй ячейке таблицы методов. Как результат, вместо hmethod вызывается gmethod.


Рисунок 2. Несовместимость, созданная типичным компилятором C++.

Эта ситуация до боли знакома разработчикам на C++. Коварство проблемы — в том, что она выглядит как проблема в классе X, который называется базовым классом в C++. Из-за этого и других подобных примеров возник миф «проблемы хрупкого базового класса». Всю вину свалили на бедный базовый класс, уводя внимание от настоящей проблемы: комбинация компилятора и компоновщика не поддерживает должным образом наследование поперёк низкоуровневого интерфейса.