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

Определение низкоуровневой совместимости между версиями

Конструирование эффективного определения низкоуровневой совместимости между версиями — непростая задача. Считайте это лобовой атакой на проблему. Пусть

A ○○ L значит, что приложение A совмещено с библиотекой L
и пусть

SAT(P, S) значит, что программа P удовлетворяет спецификации S
где P, A и L обозначают скомпилированные модули.

Наивное определение 1. L₁ — это RRBC-преемник L₀, если
SAT(A ○○ L₀, S) влечёт SAT(A ○○ L₀, S)
для всех разумных функциональных спецификаций S и для всех приложений A, использующих библиотеку L.

Проблемы конструирования этого определения выражают сложности поддержки развития скомпилированных библиотек классов. Во-первых, оператор ○○ символизирует множество различных реализаций (одна для каждой комбинации компилятора и загрузчика). Во-вторых, нет приемлемого определения «разумной функциональной спецификации». В-третьих, доказательство импликации в определении равносильно доказательству эквивалентности программ, что суть неразрешимая задача. В-четвёртых, даже, если бы эквивалентность програм не была неразрешимой задачей, устранение дефекта влечёт неэквивалентность некоторых функций библиотеки. В-пятых, даже если «разумную функциональную спецификацию» можно определить, у типичных программных продуктов едва ли имеется приемлемая формальная спецификация. В-шестых, у общедоступной библиотеки классов не определено множество приложений, использующих библиотеку (это значит, что преемник общедоступной библиотеки должен поддерживать все возможные приложения).

В свете вышеуказанных осложнений, единственный выход — это разработка инженерного дисциплины о программных библиотеках. Эта дисциплина должна быть основана на трансформациях, которые гарантированно сохраняют совместимость. Это значит, что версия библиотеки совместима только если она получена из прежней версии путём только этих трансформаций. Инженерная дисциплина в таком случае требует осторожно обосновывать те изменения в версиях, которые не достигаются трансформациями.

Цель этой инженерной дисциплины может быть выражена так:

Только изменения в приложении требуют перекомпиляции

Из этого следует, что если развитие библиотеки классов не требует изменения исходных кодов приложения, то и приложению не должна требоваться перекомпиляция.

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