Ada_Ru форум

Обсуждение языка Ада

IBM SOM: внешняя объектная система с поддержкой наследования

Оставить новое сообщение

Сообщения

Иван Левашев
IBM SOM: внешняя объектная система с поддержкой наследования
2012-10-14 01:44:38

Здравствуйте!

 

Хотел бы поделиться своей находкой: IBM SOM. Согласно Википедии, был некогда Microsoft с COM, и был IBM с SOM. В Windows и OS/2, соответственно. И было для них средства межсетевого взаимодействия: DCOM и — как вы думаете? — правильно, DSOM. Такая вот идиллия, что может сложиться впечатление, что это близнецы. Только вот в SOM было наследование, а в COM — нет, и в журналистских статейках, на которые ведут ссылки из Википедии, только об этом и речь.

 

Но это лишь вход в кроличью нору. Так как в списке рассылки есть неравнодушные к искусству программной инженерии, решил поделиться.

 

На SOM есть документация, есть обзоры, но вот такими документами, по которым можно составить впечатление (как Rationale для Ады), я бы назвал 4 статьи под авторством Scott H. Danforth и Ira R. Forman (Айра — мужское еврейское имя, если что):

 

http://www.edm2.com/index.php/Scott_H._Danforth

 

* Release-to-Release Binary Compatibility in SOM Article by Ira R. Forman, Michael H. Conner, Scott H. Danforth and Larry K. Raper (IBM's System Object Model) (1995)

* Reflections on Metaclass Programming in SOM by Ira R. Forman, Scott H. Danforth (1994)

* Inheritance of Metaclass Constraints in SOM by Ira R. Forman, Scott H. Danforth (1994)

* Composition of Before/After Metaclasses in SOM by Ira R. Forman, Scott H. Danforth, Hari Madduri (1994)

 

Самые вкусные моменты:

 

RRBC:

The goal of this engineering discipline for compiled libraries can be stated as:

*Only application alteration necessitates recompilation*

This implies that if the evolution of the class library does not require changes to the application source, then the application should not require recompilation.

 

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

 

Затем невзначай этот список продолжается другим списком трансформаций, для тех самых классов с наследованием. Приватная переменная объекта может быть добавлена, иерархия классов может измениться. Всё, что не требует изменения исходных кодов, не должно требовать перекомпиляции. Вот такой работой были заняты в IBM Object Technology Group (Austin).

 

И наконец, в RRBC приведена таблица, в которой SOM сравнивается с альтернативами (Delta/C++, OBI — мне не знакомо, но интересно было узнать). В этой таблице я, правда, не согласен с примечанием h (*).

 

Приятно радует, что авторы знакомы с CLOS и не только! В таблице по одному пункту (migrate metaclass constraint downward) CLOS уступает SOM. Более подробно эта проблема (metaclass incompatibility) рассмотрена в, например, Reflections on Metaclass Programming in SOM. Суть в том, что, когда метаклассы для классов назначаются явно, ожидается, что метакласс потомка будет потомком метакласса родителя, иначе metaclass incompatibility. Учитывая изменчивость иерархии классов и, не забывая девиз SOM, становится ясно, что то, что сойдёт с рук CLOS, не сойдёт с рук SOM.

 

В SOM 2.0 применено оригинальное решение проблемы: метакласс, указанный в IDL класса, теперь является не точным указанием метакласса для этого класса, а лишь ограничением. Метакласс класса должен быть потомком метаклассов каждого из родителей, а также потомком метакласса, указанного в объявлении класса. Если один из метаклассов является удовлетворяет всем требованиям, он и берётся. В противном случае SOM runtime принимает решение скрестить все требуемые метаклассы с целью получения минимально удовлетворяющего требованиям метакласса.

 

Заодно в этом документе разъясняется, что такое эти метаклассы. В Аде нет аналога, поэтому перескажу на примере Delphi и Java, в которых метаклассы неявные.

 

Итак, есть и в Delphi, и в Java помимо методов объекта ещё и методы класса. В Delphi также есть виртуальные конструкторы. Что касается Delphi, есть TClass, объявленный как class of TObject. Каждый раз, как в классе Delphi добавляется метод класса или виртуальный конструктор, в SOM это было бы аналогично наследованию метакласса с добавлением в него этих методов. В Delphi и Java метаклассы неявные, и цепочка их наследования почти зеркалирует цепочку наследования классов. Если новых методов класса не добавилось, можно считать, что в этом случае метакласс родителя взят без изменений. TClass и другие class of ... в Delphi ведут себя не так, как обычные объекты. У TObject есть, например, TObject.Dispatch, но у переменных типа TClass такой метод ну никак не вызвать. И любой другой метод объекта TObject не вызвать у переменных типа TClass. TClass не наследник TObject, они в других отношениях. В Java немного иначе: есть java.lang.Class и он действительно наследник java.lang.Object со всеми вытекающими. Однако, если у класса есть метод, и нам попал в руки экземпляр java.lang.Class, представляющий потомка этого класса, то вызвать какой–то метод у такого экземпляра не получится. У класса–как–объекта нет тех же методов, которые есть у класса–просто.

 

Теперь, после того, как я написал, как обстоят дела в Delphi и Java, должно быть понятно, что такое метаклассы: в SOM классы–объекты — это полноценные объекты, и их методы — это полноценные методы объекта, такие же полноценные, как и у их экземпляров. А так как у объектов методы не могут просто так болтаться, они должны быть объявлены в классе этого объекта. Класс класса — это и есть метакласс. Сам метакласс обычно в качестве своего класса имеет SOMClass, но и он, будучи полноценным объектом, может иметь какой–то другой класс. Вынуждая тем самым SOM runtime скрещивать метаметаклассы при необходимости на то.

 

In effect, inheritance is given a new dimension (RoMP)

 

Вот такой вот близнец COM с поддержкой наследования. Я писал обзор объектных систем, и SOM сияет в свете своих возможностей. (**)

 

А теперь две новости:

 

Хорошая: SOM был портирован в том числе и на Windows NT. Другими таргетами проблематично воспользоваться. AIX для PowerPC, OS/2 не каждому эмулятору PC по зубам, Himalaya NonStop — и думать нечего, Mac OS Classic — тоже как–то далековато.

 

Версия SOM 3.0 была доступна бесплатно в виде февральской беты 1996 года и декабрьского релиза, из которого некоторые возможности, которые не смогли довести до ума, вырезали.

 

Плохая: я нигде не могу найти SOMobjects 3.0 Developer's Toolkit for WinNT. Что–то случилось в 1997м или 1998м году такое страшное, что ладно бы IBM прекратила разработки в этом направлении, так нет же, надо было отовсюду вычистить из своих закоулков. На FTP я только документацию нашёл, а самих файлов нет. Только благодаря архиву Hobbes сохранилась версия для OS/2, остального — тю–тю. Поставил VisualAge C++ 4.0, думал, в комплекте идёт. Нет, не идёт.

 

Я уже начал с людьми связываться, которые в разработке участвовали, и которые сами использовали, в том числе и версию для Windows. Приятно, что отвечают, можно ещё найти кого–то, но у них нет этих файлов. Особенно меня убивает, когда так отвечают те, кто, я знаю, вложил много энергии и творческих сил в эту работу. Сегодня я написал Scott Danforth. Идеи, у кого ещё мог файлик остаться, временно исчерпаны. Ну, может, у Esther Schindler, которая писала "I have a copy of the SOM/DSOM source code somewhere in the piles of CDs here at the bitranch", всё–таки есть уцелевшие бинарники, которые можно легально распространять. Последний раз она ответила

 

I don't think we had SOM for WinNT. Or if we did I wouldn't have kept those CDs.

 

...но вдруг найдутся...

 

С уважением,

Левашев Иван

 

*) Если писать на не Objective-C, а, например, на Аде, используя привязки, которые не рассчитывают на знание размеров предков на этапе компиляции, а узнают его динамически, то так можно. А если писать на Objective-C, то как, спрашивается, реализовывать тогда [getSomething], если не обращением ко внутренним переменным? А внутренние переменные компилятор привязывает к смещению, используя информацию о внутренних переменных классов–предков. Чтобы в будущем добавлять новые поля в классы, от которые пользовательские программы наследуются, в Apple резервируют одно поле под динамические данные. В несколько раз больше обращений к менеджеру памяти, это раз. Нельзя полноценно добавлять промежуточный класс по иерархии наследования, это два, так как каждому может понадобиться такое вот приватное поле со ссылкой на то, что не влезло, а место под приватные поля ограничено размером экземпляра класса, который был однажды опубликован. В общем, на самом деле, это еле работает (barely works).

 

**) http://octagram.name/OM

 

-- If you want to get to the top, you have to start at the bottom

Отличная новость! Сегодня получил этот файлик:

http://octagram.name/pub/somobjects/som30nt.zip

 

Пробовал запускать sc.exe без параметров, ругается на то, что не может найти файлы каталогов. Скорее всего, надо читать документацию и настраивать переменные среды. По VisualAge C++ мне такие сообщения знакомы, и это гораздо лучше, чем то, что пишет полуосный sc.exe. Больше пока не могу уделять времени этому вопросу.

 

 

 

Человек, который помог в этом, сам находится в поисках версии под AIX и делал somFree для IRIX:

 

http://forums.nekochan.net/viewtopic.php?f=15&t=16726016

 

tardist я распаковать не смог, попросил выложить на хостинг исходников. Пока жду.

 

Статья стала пропуском на хабрахабр, кстати

http://habrahabr.ru/post/159139/

 

-- If you want to get to the top, you have to start at the bottom

Отличная новость! Сегодня получил этот файлик

А какое это имеет отношение к языку Ада?

25.12.2012 19:58, Vasiliy Fofanov пишет:

Отличная новость! Сегодня получил этот файлик

 

А какое это имеет отношение к языку Ада?

 

Если разобраться с этим, можно будет привязки делать не из C в Ada или не из C++ в Ada, как сейчас, преследуя только свои интересы, а из любого в SOM и из SOM в любой, и если разработчики на других языках (скажем, Delphi, Go) тоже смогут поучаствовать в том, чтобы делать SOM фасады для существующих библиотек или делать свои библиотеки сразу под SOM, и если ещё и скриптовые языки научить работать с SOM, как это было с OOREXX в OS/2, всё это будет работать и на Аду в том числе.

 

Кроме того, программная инженерия не чужда, я думаю, некоторым подписчикам рассылки.

 

ABI всегда был слабым местом объектно–ориентированных языков, и SOM отчасти исправляет это.

 

-- If you want to get to the top, you have to start at the bottom

Кроме того, программная инженерия не чужда, я думаю, некоторым подписчикам рассылки.

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

ВФ

Я не понял до конца все преимущества SOM перед COM. Наличие

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

 

- управление памятью, занимаемой объектами;

- контроль перехода вызова через границу процесса (включая локальные и удалённые вызовы);

- обработка исключений и/или наличие других механизмов донесения факта аварийного поведения вызываемой стороны.

 

Пролейте пожалуйста свет на эти вопросы если не сложно.

26.12.2012 18:09, Vadim Godunko пишет:

Я не понял до конца все преимущества SOM перед COM. Наличие

множественного наследования не есть аргумент, ибо никаких проблем COM с

этим не испытывает, было бы желание, а внутренние механизмы имеются.

 

Использование наследования средствами языка вместо средств внешней системы делает одни языки ровнее других. В COM разработчик родительского класса должен приложить дополнительные усилия для такого способа использования, в то время, как в GObject, Objective-C, SOM и WinRT это не так.

 

Значительно более интересны на мой взгляд следующие темы:

 

- управление памятью, занимаемой объектами;

 

SOM разрабатывался с прицелом на CORBA как очень важный вариант использования, и между SOM 1.0 и SOM 2.0 частный OIDL поменяли на CORBA IDL, дополненный операторами implementation { ... }. Чтобы этот IDL мог быть прочитан другими инструментами CORBA, он всегда окружён директивами условной компиляции #ifdef __SOMIDL__

 

В CORBA eсть свои политики управления памятью, и в SOM они перенимаются. Я в CORBA далеко не профессионал, просто в доках постоянно вижу эту аббревиатуру

 

Счётчика ссылок нет *), есть политики владения аргументами и результатами, для которых в IDL предусмотрены атрибуты. Надо полагать, это тоже из CORBA

 

http://www.warpspeed.com.au/cgi-bin/inf2html.cmd?..\html\book\Toolkt40\SOMGUIDE.INF+264

 

- контроль перехода вызова через границу процесса (включая локальные и

удалённые вызовы);

 

DSOM реализует CORBA 1.1 и как ORB, и как расширение SOM. При помощи метапрограммирования можно перехватывать как сами вызовы, так и навешивать before/after действия. Если какой–то класс скрестить с SOMDClientProxy, такой потомок имеет интерфейс исходного класса, но поведение прокси. Гибкость SOM достаточна для программирования особого поведения удалённых объектов. Replication Framework позволяет дублировать объекты вместо создания удалённых ссылок.

 

- обработка исключений и/или наличие других механизмов донесения факта

аварийного поведения вызываемой стороны.

 

Через Environment, передаваемый последним аргументом. Как в CORBA.

 

(*) Даже, если счётчик ссылок не реализован, можно сделать свои базовые класс–потомок SOMObject и наследовать остальные классы только от него. Скажем, в современном Objective-C всё наследуется от NSObject, хотя исторически настоящий корень — просто Object, и этот корневой класс не поддерживает retain/release.

 

http://www.warpspeed.com.au/cgi-bin/inf2html.cmd?..\html\book\Toolkt40\ODPGREF2.INF+7

 

-- If you want to get to the top, you have to start at the bottom

Я весьма скептически отношусь к идее общей среды для построения абстракций на разных ЯП. У каждого ЯП свои методы построения абстракций. Даже если это ООП, то оно ну просто очень разное. Сравите ООП в смалтолке, с++ и Go.

Ну и опять таки на ООП свет клином не сошелся. Не везде оно применимо и не везде его следует применять. Часто много удобней использовать что-то другое.

27.12.2012 1:27, Alexey Veselovsky пишет:

 

 

Я весьма скептически отношусь к идее общей среды для построения

абстракций на разных ЯП. У каждого ЯП свои методы построения абстракций.

Даже если это ООП, то оно ну просто очень разное. Сравите ООП в

смалтолке, с++ и Go.

 

Как минимум, C++ и SmallTalk держались в уме при проектировании SOM, ведь у IBM был инструментарий для этих языков. IBM Object COBOL без SOM и вовсе не работал, судя по документации (после устаревания SOM его перевели на Java).

 

Насчёт Go не знаю, но подозреваю, что вызов метода объекта — это абстракция, которая более менее подходит для всех языков, на которых можно вызывать .dll и создавать .dll

 

И SOM — это не только ООП. Это ещё и культура компонентного программирования, которой не достаёт многим, особенно, open source, библиотекам. А именно, возможность выдрать с мясом что–то такое из всех своих зависимостей, так что, поместив это что–то в свой проект, можно сделать его компилируемым вне зависимости от наличия всех зависимостей у того, кто компилирует.

 

То есть, не может быть такой ереси, как configure --with или --without. Вариант сборки был бы только один, и то, будет ли очередная фича доступна или нет, зависело бы только от наличия нужной .dll во время исполнения, а не от того, как был сконфигурирован проект перед сборкой.

 

-- If you want to get to the top, you have to start at the bottom

А кстати, оно похоже таки шевелится: somFree:

http://www.linux.org.ru/news/opensource/8720587

 

 

2013/1/2 Иван Левашев <[email protected]>

Новое сообщение:
Страницы: 1

Чтобы оставить новое сообщение необходимо Зарегистрироваться и Войти