Хотел бы поделиться своей находкой: IBM SOM. Согласно Википедии, жил да был некогда Microsoft с COM, и был IBM с SOM. В Windows и OS/2, соответственно. И были для них средства межсетевого взаимодействия: DCOM и — как вы думаете? — правильно, DSOM. Такая вот идиллия, что может сложиться впечатление, что это близнецы. Только вот в SOM было наследование, а в COM — нет, и в журналистских статейках, на которые ведут ссылки из Википедии, только об этом и речь.
Но это лишь начало путешествия в кроличью нору.
На SOM есть документация, есть обзоры, однако такими документами, по которым можно составить впечатление, я бы назвал 4 статьи под авторством Scott H. Danforth и Ira R. Forman (Айра — мужское еврейское имя):
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 — мне не знакомо, но интересно было узнать). В этой таблице я, правда,
Приятно радует, что авторы знакомы с 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
Вот такой вот близнец COM с поддержкой наследования.
Я писал обзор объектных систем, и SOM сияет в свете своих возможностей.
А теперь две новости:
Хорошая: SOM был портирован в том числе и на Windows NT. Другими таргетами проблематично воспользоваться. AIX для PowerPC, OS/2 не каждому эмулятору PC по зубам и денег стоит, Himalaya NonStop — и думать нечего, Mac OS Classic — тоже как–то далековато.
Версия SOM 3.0 была доступна бесплатно в виде февральской беты 1996 года и декабрьского релиза, из которого некоторые возможности, которые не смогли довести до ума, вырезали. Например, Direct-To-SOM позволял не .h делать из .idl, а, наоборот, .idl из .h. Пишем на модифицированном компиляторе C++, получившийся код использует SOM и благодаря этому становится гибким. В отличие от Delta/C++, возможными потребителями библиотек автоматически становятся другие компиляторы C++ и компиляторы других языков программирования.
Плохая: я нигде не могу найти SOMobjects 3.0 Developer's Toolkit for WinNT. Что–то случилось в 1997м или 1998м году такое страшное, что ладно бы IBM прекратила разработки в этом направлении, так нет же, надо было отовсюду вычистить SOM из своих закоулков. На FTP я только документацию нашёл, а самих файлов нет. Только благодаря архиву Hobbes сохранилась версия для OS/2, остального — тю–тю. Ставил VisualAge C++ 4.0, думал, в комплекте идёт. Нет, не идёт.
Я несколько месяцев назад начал с людьми связываться, и которые в разработке участвовали, и которые сами использовали, в том числе и версию для Windows. Приятно, что отвечают, можно ещё найти кого–то, но у них нет этих файлов. Особенно меня убивает, когда
Hi, Ivan,
I'm sorry to say that although I was the chief programmer for release 1 and 2 of SOM (I even signed the disks that were to be used as the general availability media and sent to production) I had left the company by the time 3.0 came out and had no contact with the team at that point.
I don't know anyone who has the binaries at this time. It is a shame that IBM marketed SOM so poorly — for a while there we thought we were going to change the world.
Sorry I can't help you.
andy
Идеи, у кого ещё мог файлик остаться, временно исчерпаны. Насколько я могу судить, на физическом носителе SOM 3.0 не распространялся по отдельности. На CD-ROM должны быть версии и для OS/2, и для WinNT, и для AIX. Судя по имени файла som30os2.zip (всё, что сохранилось в Интернет), это версия именно с CD-ROM. Internet-sized файлы имели другие имена: som30ox1.zip, som30ox2.zip and som30ox3.zip.
Что дальше?
Во–первых, при некотором интересе к SOM могут–таки найтись недостающие файлики. По моему мнению, до сих пор актуальные, даже учитывая потребность в версиях для Linux и Mac OS X. Мне нравится идея исполняемых файлов в формате PE COFF, умеющих обнаружить исполнение внутри wine, загрузить родные для OS версии wxWidgets или Qt и, используя их, забыть свои корни. Даже не имея исходных кодов SOM, можно иметь пользу, а наличие работающего SOM и работающего кода, использующего SOM, поможет создать совместимую замену. Линуксовый wxWidgets так запросто не получится использовать из программы, компилирующейся в Windows. Тут–то и пригодилась бы прослойка, и почему бы не SOM?
Во–вторых, сама по себе осведомлённость о SOM — это матрица в сознании, влияющая на принятие решений разработчиками. У тех, кто разрабатывал GObject, такой матрицы в сознании не было, и GObject в SOM так и не вырос.
Автор: OCTAGRAM
