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

В SOM классы — это объекты, чьи классы называются метаклассами. Класс отличается от обычного объекта тем, что среди его полей есть таблица методов экземпляра, определяющая, какие методы поддерживают экземпляры класса. В течение инициализации объекта класса у него вызывается метод, оповещающий родительские классы. Это позволяет классу построить первоначальную таблицу методов экземпляра. Затем у класса вызываются другие методы, чтобы переопределить унаследованные методы или добавить новые методы экземпляра.

На диаграммах классовых иерархий в этом докладе применяется соглашение, что метаклассы обозначены трёмя концентрическими окружностями, обычные классы (то есть, классы, которые не метаклассы) обозначены двумя концентрическими окружностями, а обычные объекты (то есть, объекты, которые не классы) обозначены одиночными окружностями. Начальное состояние условной программы на SOM обозначено на рисунке 1. Всего 4 объекта: SOMObject (класс), SOMClass (метакласс), Dog (обычный класс), и Rover (обычный объект). Между объектами вводится два вида отношений, которые необходимо понять.


Рисунок 1. Примеры различных объектов SOM.

Во–первых, отношение экземпляр-чего между объектами и классами изображено штриховой стрелкой от объекта к его классу. По обстоятельствам, также изображается обратное отношение класс-чего. SOMObject — это экземпляр SOMClass, а SOMClass — это экземпляр самого себя. Класс объекта требуется, поскольку объект поддерживает только те методы, которые определены его классом (то есть, методы, которые класс привносит или наследует).

Во–вторых, отношение между классами, называемое отношением подкласс-чего, изображено сплошной стрелкой от класса ко всем его родителям. SOMClass — это подкласс SOMObject. У SOMObject нет родителей. SOMObject привносит методы, которые должны поддерживаться всеми объектами в SOM. Будучи подклассом SOMObject, SOMClass — это объект, но дополнительно он привносит методы, которые должны поддерживаться всеми классами. Например, SOMClass привносит метод somNew, кототорый создаёт экземпляр класса. Также привносятся методы, отвечающие за создание и изменение таблицы методов экземпляра. Абсолютно все метаклассы в SOM наследуются от SOMClass. (Похожее устройство классов также применяется в других объектных моделях, например, CLOS и Dylan.) SOMClass и SOMObject — это два класса в ядре SOM.

Интерфейсы объектов SOM описываются при помощи IDL, языка описания интерфейсов объектов (Interface Definition Language), определённого стандартом Общей архитектуры брокера объектных запросов (Common Object Request Broker Architecture, CORBA) рабочей группы Object Management Group (OMG). SOM IDL — это совместимая с CORBA версия IDL, используемая, чтобы описания классов SOM были рядом с определениями интерфейсов объектов. (Таким образом, интерфейс класса описывается обычным IDL, а SOM IDL добавляет дополнительную информацию о реализации.) В составе SOMobjects Toolkit есть инструменты, называемые эмиттерами, которые транслируют SOM IDL в привязки для выбранного языка программирования к объектам соответствующих классов (то есть, для разработчиков на языке Си это значит, что эмиттер создаёт заголовочные файлы как для использования класса, так и для реализации). Вдобавок, существуют компиляторы C++, производящие код, непосредственно использующий SOM.

Ниже представлена базовая структура определения IDL для объектного интерфейса под названием Dog. В то же время, это описание SOM IDL класса Dog, поддерживающего этот интерфейс. #ifdef и #endif (которые для простоты опущены в последующих примерах) — это часть языка IDL, и используются для сокрытия секции реализации класса SOM от компиляторов, не поддерживающих SOM IDL.

interface Dog : SOMObject {
   <method and attribute declarations here>
   #ifdef __SOMIDL__
   implementation {
      metaclass = SOMClass;
      <instance variable declarations here>
   };
   #endif
};

В этом примере интерфейс Dog наследуется от интерфейса SOMObject, и в то же время класс Dog объявлен как подкласс SOMObject. CORBA и SOM поддерживают множественное наследование; дополнительные родители Dog могут быть указаны вместе с SOMObject через запятую. Собственно методы и поля Dog не представляют интереса в текущем контексте. Как показано в этом примере, секция реализации может явным образом указывать метакласс, связанный с классом объектов, поддерживающих определяемый интерфейс. Эта связь, однако, не всегда прямая. По причинам, которые станут ясны позже, настоящий класс описанного SOM IDL класса — в общем случае подкласс указанного метакласса.