Низкоуровневая совместимость между версиями, Перевод «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 — это больше, чем теория; она активно применялась и в IBM, и в сообществе OS/2 более трёх лет. Многочисленные приложения для OS/2 и системные средства, такие как IBM LAN Server, MMPM/2, Ultimail, IBM Works и даже OS/2 Workplace Shell (пользовательский интерфейс OS/2) созданы с использованием технологии SOM. Даже такие умеренного размера приложения, как эти, содержат дюжины, а иногда сотни классов SOM. Эти приложения были разработаны независимо и потом развивались, даже когда сам SOM менялся.

Рисунок 9 показывает ход истории для технологии SOM и операционной системы OS/2. Дебют SOM 1.0 состоялся в апреле 1992; он был ключевой частью первого 32-битного выпуска OS/2 2.0. Хотя версия SOM 1.0 поддерживала только примитивное одиночное наследование, многие из RRBC возможностей, описанные в этом докладе, уже присутствовали. Именно это изначальное присутствие возможностей RRBC позволило технологии развиться.

Версия SOM 2.0 совершила значительный рывок с точки зрения новых возможностей. Это была первая попытка среди всех коммерческих продуктов поддержать зарождающийся стандарт CORBA 1.1. Для SOM это значило переход на новый язык определения для SOM интерфейсов, расширения собственно базовой объектной модели (например, множественное наследование) и изменения в инфраструктуре, чтобы поддерживать распространение через брокер объектных запросов (Object Request Broker, ORB), известный как DSOM. Поскольку циклы продуктов OS/2 и SOM были совершенно независимы, SOM 2.0 появился в независимо лицензируемом продукте под названием SOMobjects Developer Toolkit. В дополнение к базовым инструментам разработки для SOM этот инструментарий также включал широкий набор каркасов для приложений и демонстрационных программ. Будучи установлен на любой операционной системе OS/2 2.0 или 2.1, инструментарий SOM полностью замещал более раннюю версию SOM. Так что, даже если никакое из приложений SOM для OS/2 ещё не воспользовалось преимуществами новых возможностей SOM 2.0, все каркасы, сделанные на SOM, продолжали работать без перекомпиляции, в то время как только что созданные каркасы, использующие SOM 2.0, выполнялись рядом в той же среде.


Рисунок 9. Развитие SOMobjects Toolkit и OS/2 Workplace Shell.

В октябре 1994 версия SOMobjects Toolkit 2.1 была выпущена в общий доступ; этот выпуск SOM поправил некоторые обнаруженные дефекты (разработчики SOM не более особенные, чем другие) и во многом улучшил производительность. В это время циклы продуктов OS/2 Warp и SOM совпали более удачно, и SOM 2.1 был включён как внутренний элемент Warp. Важно заметить, что разработка OS/2 Warp Workplace Shell началась (в Бока Ратон, Флорида) с использованием ядра SOM 2.0, в то время как команда разработчиков SOM в Остине, Штат Техас, закончила версию 2.1. Только в последние дни подготовки Warp (июль 1994) команда разработчиков Workplace Shell получила новое ядро SOM 2.1. Благодаря RRBC в SOM, они могли тестировать без перекомпиляции; давая разработчикам SOM возможность действовать независимо, что было необходимо для удовлетворения требований к продукту, не влияя на график разработчиков Workplace Shell.

Этот опыт — один из многих похожих опытов, которые можно привести в качестве эмпирического подтверждения пакетной технологии SOM. Но более важно то, что благодаря упору на RRBC в SOM такая разработка независимо поставляемых скомпилированных библиотек классов должна считаться нормой.