Низкоуровневая совместимость между версиями, Перевод «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 позволяет и поощряет определения и явное использование метаклассов. С учётом этого более широкого ABI наша инженерная дисциплина требует ещё одну дополнительную трансформацию.

Трансформация 15: Класс класса (то есть, ограничение на метакласс) может мигрировать вниз по иерархии классов.

Эта трансформация аналогична Трансформации 8 в том, что когда метакласс мигрирует вниз, новый метакласс поддерживает весь функционал старого метакласса. Однако, существуют ограничения на приемлемость нового метакласса.

Рассмотрим следующий простой пример, изображённый на рисунке 5. На этом рисунке X — это экземпляр XMeta; мы принимаем, что XMeta поддерживает метод bar и что X поддерживает метод foo, содержащий выражение bar(class(self)). Таким образом, метод foo вызывает метод на классе объекта, у которого вызван foo. Теперь посмотрим, что случится, если X наследуется Y, классом, у которого в SOM IDL явно указан метакласс, как на рисунке 5. Если бы иерархия классов образовывалась как на рисунке 5, вызов foo на экземпляре Y не сработал, поскольку YMeta не поддерживает bar. Эта ситуация называется несовместимостью метаклассов.

interface X {
   ...
   void foo();
   implementation{
      metaclass = XMeta
   };
};
where
   foo()
   {...
      bar(class(self));
      ...};

interface Y:X {
   ...
   implementation{
      metaclass = YMeta
      ...

Рисунок 5. Пример несовместимости метакласса.

SOM не позволяет создавать иерархии с несовместимостями метаклассов. Вместо этого, SOM создаёт производные метаклассы, которые предотвращают появление этой проблемы. Настоящая иерархия классов SOM, которая образуется для Y, изображена на рисунке 6, где SOM автоматически создала метакласс DerivedMetaclass; это гарантирует, что вызов foo на экземплярах Y сработает. Этот пример показывает, что оператор metaclass в SOM IDL обрабатывается как ограничение на итоговый метакласс. Производный метакласс — это в некотором смысле минимальный метакласс, удовлетворяющий ограничениям совместимости метаклассов.

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

Сейчас все языки должны решать проблему несовместимости метакласса. Например, C++ решает проблему тем, что в нём нет метаклассов. Smalltalk решает проблему тем, что не позволяет явно указывать метакласс. CLOS содержит правило для проверки совместимости во время создания класса, исключающее возможность несовместимости метакласса (тем, что неудача при проверке совместимости приведёт к ошибке времени исполнения). Только SOM обрабатывает несовместимость метаклассов, не ограничивая разработчика.


Рисунок 6. Пример произведённого метакласса.