to post messages and comments.

← All posts tagged ООП

@OCTAGRAM:

putting.om.Environment.solveMetaclassConstraints
Нашёл ту функцию, которая подбирает нужный метакласс или конструирует новый, если ни один из запрошенных не подходит. На всё про всё 40 строк кода. Вот, насколько упростил Гвидо ван Россум свой Питон, отказавшись это сделать, и сломав метаклассы по сравнению с моделью из книги, которой он вдохновлялся.

The metaclasses book describes a mechanism whereby a suitable metaclass is automatically created, when necessary, through multiple inheritance from M1 and M2. In Python 2.2, I have chosen a simpler approach which raises an exception if the metaclass constraint is not satisfied; it is up to the programmer to provide a suitable metaclass through the __metaclass__ class variable. However, if one of the base metaclasses satisfies the constraint (including the explicitly given __metaclass__, if any), the first base metaclass found satisfying the constraint will be used as the metaclass.

@OCTAGRAM:

Unifying types and classes in Python 2.2
One of the coolest, but perhaps also one of the most unusual features of the new classes is the possibility to write "cooperative" classes. Cooperative classes are written with multiple inheritance in mind, using a pattern that I call a "cooperative super call". This is known in some other multiple-inheritance languages as "call-next-method", and is more powerful than the super call found in single-inheritance languages like Java or Smalltalk. C++ has neither form of super call, relying instead on an explicit mechanism similar to that used in classic Python. (The term "cooperative method" comes from "Putting Metaclasses to Work".)Таким образом, в этом отношении Питон продвинулся вперёд по сравнению с SOM. В реальном SOM множественное наследование было реализовано как в C++, топорно и без всяких порядков вызова методов. Соответственно, никакого call-next-method, а вместо этого указатель на унаследованную реализацию получался единоразово во время инициализации класса, либо потом можно было запросить его ещё раз, указав свой класс и индекс родительского класса. Эмиттеры все эти индексы заворачивали в соответствующие имена родительских классов. При этом во весь вставала проблема ромбовидных иерархий, когда к родительским классам вызовы могут либо не приезжать, либо приезжать несколько раз. Чтоб совсем плохо не было, конструкторы, деструкторы и операции присваивания в SOM пользовались битовыми полями (один класс — один бит), отсекающими повторные вызовы. Кооперативные методы, скорее всего, были только в книге. Metaclass Framework в составе SOM был закрытой библиотекой без IDL. Бетатестеры могли получить их по запросу. Так как всего этого нет, однозначно утверждать, что MRO не было, нельзя, но по крайней мере, в общем доступе кооперативных методов не было. До Питона они были только в книге.

The metaclasses book describes a mechanism whereby a suitable metaclass is automatically created, when necessary, through multiple inheritance from M1 and M2. In Python 2.2, I have chosen a simpler approach which raises an exception if the metaclass constraint is not satisfied; it is up to the programmer to provide a suitable metaclass through the __metaclass__ class variable. However, if one of the base metaclasses satisfies the constraint (including the explicitly given __metaclass__, if any), the first base metaclass found satisfying the constraint will be used as the metaclass.А вот тут, к сожалению, сделан шаг назад к семантике CLOS. В SOM 2.0 это было, и, конечно, это было в книге. Возможно, что (кроме длительной недоступности книги, пока я её не отсканил) это причина, почему метаклассы в Питоне не столь развиты. Ведь с таким геморроем ими резко становится не так удобно пользоваться.

@OCTAGRAM:

J. Hamilton. A model for implementing an object-oriented design without language extensions
Почитал. Выходит, селекторы должны указывать на смещение внутри таблицы виртуальных методов, а эти таблицы в общем случае должны предусматривать селекторы вообще для любого метода любого класса, а то, что на самом деле там их меньше, — это оптимизация. Этот доклад ссылается на объектные модели Smalltalk и Objective-C, в которых одиночное наследование, при этом ссылка на этот доклад найдена в книге «Programming with DirectToSOM C++», где модель однозначно поддерживает множественное наследование. Однако, в принципе, понятно, как применить одно к другому. В случае Smalltalk и Objective-C объектная модель плоская, допускающая коллизии между селекторами никак не связанных между собой классов, и именно разруливанию этих ситуаций посвящён доклад. А в SOM одноимённые методы классов так конфликтовать не могут, поскольку жетоны методов функционально эквивалентны кортежу из ссылки на класс-объект и имени метода. Однако конфликт возникает в другом месте, если мы пытаемся сделать у каждого класса таблицу виртуальных методов с поиском по индексу. Любое множественное наследование приводит к тому, что на один и тот же слот в таблице виртуальных методов начинают претендовать не подозревавшие о существовании друг друга классы, у которых появился общий потомок. В этом случае можно таблицы виртуальных методов родительских классов раздвинуть так, чтобы потомки не могли конфликтовать, и уже без проблем произвести таблицу виртуальных методов наследника. Приходится попариться при создании классов, зато потом всё летает. Хотя я ещё не исследовал перемычки SOM и не знаю, как оно там было на самом деле.

@OCTAGRAM:

Approaches to Composition and Refinement in Object-Oriented Design
MN93 shows that framework refinement (in the sense of adapting a frame-work to yield another abstract framework) is not possible under either co-variant(Eiffel) or contravariant (Modula-3) typing rules.Надо бы как-нибудь ликвидировать свою безграмотность по части ковариантного и контравариантного вот этого всего.

@OCTAGRAM:

По результатам плотной работы с SOM обнаруживается горькая правда, что множественное наследование там не как в «Putting Metaclasses to Work», CLOS, Dylan и Python, а как в C++. Линеаризации классов, порядка разрешения методов просто нет. Можно либо вызывать только первого родителя среди тех, кто поддерживает метод, либо какого-то конкретного, либо всех, и тогда в ромбовидных диаграммах наследования кому-то будет прилетать многократно. Конструкторы, деструкторы и операция присваивания, чтоб совсем плохо не было, защищаются битовыми полями. Я их и раньше видел, но мне казалось, это связано с тем, что конструкторам может требоваться передавать управление в нестандартном порядке, а обычные методы просто вызовут, что им дал somParentResolve, и попадут куда надо. Эдак довольно солидная часть книжки становится неприменимой к имеющимся бинарникам. То, что описано в книге как то, с чем авторы имели опыт, действительно было таковым, но в общий доступ не попало:
SOM DTK v3.0 Programming Guide на странице 205 (187):
Customizing method resolution requires the use of metaclasses that override SOMClass methods. This is not recommended without use of a Cooperation Framework that guarantees correct operation of SOMobjects in conjunction with such metaclasses. SOMobjects users who require this functionality should request access to the experimental Cooperation Framework used to implement the SOMobjects Metaclass Framework. Metaclasses implemented using the Cooperation Framework may have to be reprogrammed in the future when SOMobjects introduces an officially supported Cooperation Framework.

@OCTAGRAM:

Раздраконил свой генератор привязок до такого состояния, что уже заработала программа, использующая исключительно новые привязки. Это пример для старых привязок, а это — для новых. В старых привязках SOMObject — это указатель на запись, а все остальные классы — синонимы SOMObject, то есть, контроля типов нет. В старых привязках, чтобы узнать тип аргумента, нужно было в процедурном стиле написать ParameterDef__get_type, а вот имя аргумента объявлялось в Contained, поэтому Contained__get_name, а так как вручную мне лень синонимы везде прописывать, то только по таким именам работало. В новых привязках генератор собирает все методы класса в одну общую кучу, и всё работает достаточно очевидным образом с вызовом методов через точку. И даже атрибуты CORBA спроецировались на свойства Delphi. Поскольку в Delphi жалкое одиночное наследование, генерить список методов требуется каждый раз сначала, и именно это и делается, зато потом удобно.

Работает это посредством того хака, что создаются объекты SOM, а Delphi думает, что это объекты Delphi. Так как с точки зрения Delphi методы статические, Delphi не лезет в VMT, делает статический вызов, в нём написан код, который направит вызов в SOM, и оно там пойдёт куда надо. Ещё немного пошаманил, чтобы волшебным образом работали классовые функции. Классовые функции могут вызываться как у объектов, и тогда Delphi пытается взять из объекта VMT по нулевому смещению, а может — непосредственно у класса, и тогда берётся статический адрес VMT. Учитывая, что с точки зрения Delphi классы друг от друга не наследуются, отличить эти случаи не сложно. Нужно просто сравнить Self со своим именем, и если да, то нас вызвали через имя класса, и класс-объект нужно искать одним способом, а если нет, то нас вызвали как метод объекта, и надо ещё раз разъименовать Self, и там будет лежать указатель на класс-объект.

Немного подкрутил, чтобы в результате метода SOMObject.somGetClass учитывался метакласс. Была мысль вообще все методы метакласса спроецировать на классовые функции и процедуры, но потом посмотрел, сколько там всего в SOMClass, и решил, что не надо. Тем более, что в SOM.IR публично показан только один метакласс, SOMMSingleInstance. Но даже ради него подкрутил, чтобы у метода SOMObject.somGetClass возвращался именно указанный метакласс, а не просто SOMClass. Кстати, так получается, что с точки зрения языковой проекции метаклассы не могут так просто наследоваться. То есть, умом-то мы понимаем, что компилятор SOM гарантирует совместимость метаклассов, но вот во что это спроецировать, открытый вопрос. Если мы наследуемся от двух классов с разными метаклассами, то метакласс потомка будет заведомо принадлежать пересечению множеств потомков каждого метакласса, и что, для этого динамически создаваемого метакласса тоже создавать привязки? А там по цепочке ещё для метаклассов более высокого порядка может потребоваться автоматическое создание. Одно дело — когда движок SOM это создаёт, и другое дело — когда генерится текст. Я решил, что этого делать не нужно, а раз так, то даже, если был класс A с указанием метакласса M_A, и от него наследуется класс B, то, если B не укажет явно тот же метакласс, что и A, в его привязках будет опять обычный SOMClass.

Естественно, все методы обычного TObject не будут работать. Я эту проблему пытаюсь решить, скрывая их при помощи reintroduce в private. Только операция as портит картину. Её не спрячешь, но хотя бы заменил методами, приводящими тип вверх и вниз. Вот так, с небольшой порцией магии создаётся впечатление, что SOM в Delphi как родная. Классы, методы, свойства.

@OCTAGRAM:

Про интерфейсы и классы:
В COM замороженность интерфейсов диктовалась техническими ограничениями, во всяком случае, это то, что на виду. Однако, если присмотреться, то даже в виртуальных машинах, сценарных языках программирования и т. п. окружениях, где технические проблемы решены, мы не можем просто взять и расширить интерфейс, так как интерфейс может быть реализован вообще каким угодно классом, и не согласованные с другими командами разработчиков расширения интерфейса сломают их классы. А вот если есть класс с реализацией по умолчанию, то этот класс можно расширять, и все довольны. Так приходим к мысли о том, что множественное наследование всё–таки нужно, а так называемое «множественное наследование только для интерфейсов» — это пыль в глаза. На самом деле нет, а звучит как будто есть.

Естественно, под множественным наследованием я не имею в виду убожество из стандарта C++.

@OCTAGRAM:

octagram.name
Есть такая книга, Saba Zamir, «Handbook of Object Technology», в моей квартире толще неё, наверное, только БСЭ, там обо всём помаленьку. Нравится мне тем, что в этой книге нашлось места и для Ada, и для SOM, и для Object Pascal, и ещё много чего, о чём я не знал, но, может быть, найду время почитать.

Для своей эпохи довольно важная, каждый, кто хотел иметь отношение к объектным технологиям, стремился в эту книгу попасть (Saba Zamir там в роли редактора, а у каждой главы свой автор). Полное оглавление можно посмотреть здесь и даже купить отдельную главу за $20. Многие главы после публикации в книге были переопубликованы в Интернете, такие главы я надёргал отдельными файлами. Например, много, где лежит PDF «An Overview of the C++ Programming Language» под авторством Ricardo Devis, Bjarne Stroustrup, и там в самом начале написано «From The Handbook of Object Technology (Editor: Saba Zamir). CRC Press LLC, Boca Raton. 1999. ISBN 0-8493-3135-8» — как раз из этой книги. А какие–то главы, которые были мне особо интересны, я надёргал в Google Books: books.google.ru
Делать это получалось с переменным успехом, Google показывает не все страницы, но для разных IP скрыты разные, причём, я года два назад трёх провайдеров поменял, и ещё с работы заглядывал, но так и не все страницы взял. Сегодня ещё раз заглянул с ещё одного места, и белые пятна в интересных мне главах практически ликвидировал. Одна страница с парой–тройкой элементов списка литературы осталась скрытой. Переживём как–нибудь без списка литературы, я этой литературы всё равно накачал изрядно, читать — не перечитать.

Интересовал меня раздел V Object Technology Standards and Distributed Objects, а в нём главы с 28ой по 32ую. Там и про CORBA, и про SOM, и про DSOM; а самая последняя глава — про COM. Там я вроде тоже всё знаю, но на всякий случай выдернул и её тоже. Другой интересный раздел был посвящён ООП в разных языках программирования. То, что касается Ada 95, выдернул почти всё, ещё на всякий случай Modula-3, SmallTalk, Objective-C, но там с пробелами. Про Object Pascal я и так всё знал, поэтому даже не выдёргивал. Если в Google Books много страниц посмотреть, он начинает прятать всё большими кусками, так что когда пролистал то, что мне интересно больше всего, остальное оказывается скрыто. Физически книга есть у меня дома ( octagram.name ), если что–то ценное, могу так почитать или отсканировать.

До сих пор загадка, как это IBM так сдулись, и их технологии вычеркнулись отовсюду, как в «Черновике» Лукьяненко или как в Потерянной комнате. Своим физическим присутствием книга работает как свидетельство. Собственно описание SOM там гораздо проще, чем остальное, что я читал по этой теме.

@OCTAGRAM:

ru.wikipedia.org
Выложил всё, что мне известно про языки программирования, с которыми был хоть как–то связан SOM. Оказывается если посчитать, их целых 8.

@OCTAGRAM:

drive.google.com
Копия: octagram.name (21 Мб)
Приложение к книге: octagram.name

Теперь можно нормально читать «Putting Metaclasses to Work: A New Dimension in Object-Oriented Programming» by Ira R. Forman, Scott H. Danforth.
Martin Iturbide сделал OCR и собрал всё в PDF. Размер уже вменяемый, но состояние ещё сыроватое. Страницы не повёрнуты, чёрный цвет букв выглядит серым и прочие недостатки, которые, наверное, не критичны.
Если есть умельцы, которые хотят и могут сделать лучше, можно скачать 400 dpi сканы здесь: octagram.name (900Mb) Я думаю, Мартин в будущем ещё улучшит качество сам.

Меня потом будет интересовать, как отправить эту книгу в 100500 либрусеков, чтоб везде была

@OCTAGRAM:

octagram.name

24 апреля 2007 года некто Guido van Rossum оставил комментарий к книге «Putting Metaclasses to Work»:

Too bad this is out of print; I keep referring to it as the best tutorial I know for the difficult subject of cooperative multiple inheritance, supported by Python via the super() function.
amazon.com

Книга изначально стоила $39.95. Б/у книги обычно дешевеют, но эту книгу я был счастлив найти б/у за $51, потому что цена на б/у обычно не меньше $80. По моему мнению, если б/у книга дороже новой, когда новая была в печати, это признак, что надо допечатывать новые тиражи. При всём при этом книгу так и не удалось найти в p2p. С книгой, наконец, случилось то, что и должно было. Она отсканирована (первая ссылка), но ничего, кроме этого пока не сделано, и когда будет сделано, не знаю. Я вообще раньше никогда не переводил книги в цифру.

Размеров бояться не надо. Если обложка весит в цвете 23Мб, то типичная страница в оттенках серого получается на 2-4, редко 6Мб. В сумме 1Гб. Разрешение 400dpi. К книге по–хорошему должен был прилагаться CD-ROM или Floppy, но кто–то очень умный решил вместо этого разместить вложение в Интернете. Вложение упомянуто, например, на странице xiii (временный адрес octagram.name ). Как это обычно бывает в таких случаях, фиг там уже что скачаешь. awl.com теперь перенаправляет на сайт нового владельца: informit.com

На сайте написано «Register your product to gain access to bonus material or receive a coupon.», но ничего там в личном кабинете, конечно, не появилось после регистрации, а техподдержка пишет:

Dear Ivan,

If you have registered the textbook but are unable to locate the desired resources, then those resources may no longer exist.

Because this book is 16 years old and out of print since 2001, many of its resources are no longer supported and available online.

We apologize for any difficulty or inconvenience this has caused you.

Основательно поколдовав с Internet Wayback Machine, файлик получилось найти и сохранить: octagram.name

@OCTAGRAM:

Есть одна такая книга по программированию: «Putting Metaclasses to Work by Ira R. Forman, Scott Danforth, Addison-Wesley 1999».
Её в последнее время чаще всего упоминают в контексте реализации метаклассов, а также в контексте произхождения Python, в котором метаклассы реализовывались по этой книжке. Так, например, в статье в Wikipedia про метаклассы en.wikipedia.org (в руской Wikipedia аналогично) эта книга — первая в сносках, а последующие — про метаклассы в Python, идеи для которого были взяты из неё же:

python-history.blogspot.ru
I was inspired to implement new-style classes by a very specific book, "Putting Metaclasses to Work" by Ira Forman and Scott Danforth
books.google.ru

В книге описываются возможности метаклассов на примере модифицированного C++, который их поддерживает. Этот язык не вымышленный, под него были компиляторы. Ira (Айра) R. Forman имеет прямое отношение к разработке IBM SOMObjects DTK 3.0, частью которой предполагалось сделать технологию D2SOM (DTS, Direct-to-SOM) — когда компилятор, например, C++, способен напрямую компилировать код для C++ в объекты SOM, сам создаёт файлы .idl. Технологию так и не доработали, и в SOM 3.0 она так и не вошла, а потом у IBM началась череда странностей, в результате которой и OS/2 ушла, а вместе с ней и куча технологий, для которых она была плацдармом. И у Apple с Copland не заладилось, надо же было так совпасть. В принципе, если DTS хочется посмотреть, в компиляторах для OS/2 она есть и, может быть, даже в VisualAge C++ 3.5.6 для Windows тоже, у меня этой версии нет, не проверял.

При всём обилии ссылок на эту книгу найти её в электронном виде в Greylink DC++ p2p или хотя бы из Google Books по страничке надёргивать с разных IP, как это было с «Saba Zamir: Handbook of object technology», не получилось. Её, похоже, нет в сети вообще. Она вышла из печати, а те магазины, где она ещё есть, радуют ценниками в 90 долларов. Не могу сказать, что это проблема книги, скорее проблема нашей айтишной индустрии. Когда кажется, что с новыми мощностями железа мы с удвоенной скоростью помчимся к новым достижениям, случается фазовый переход, и вместо прогресса получается одурение, прогресс вроде бы не нужен, если вот прямо сейчас можно поставить несколько временных костылей, и вся эта мощь начинает тратиться на костыли, а то, что можно было бы переписать и улучшить, так и застывает, вроде бы и не надо ничего менять, и так работает. Нет ничего более постоянного, чем временное. Вот и с технологией программирования так же. Всё то, что я написал, мало, кому известно, а чего–то лучше и не создано. Всё как–то застыло.

На этой неделе я наконец–то получил эту книгу.

@OCTAGRAM:

octagram.name
Вот это я понимаю, нормальная цена для книги. Жалко, на доставке погорю

@OCTAGRAM:

Долгое время не могу найти в электронном виде Saba Zamir, Handbook of Object Technology crcnetbase.com

В p2p мне известны две магнитные ссылки: magnet:?xt=urn:tree:tiger:5LT56SKGOL2H2LGSGIGVRWVJUEH2D22LYRVDZHQ&xl=19198295&dn=CRC+Press+-+Handbook+of+Object+Technology.zip magnet:?xt=urn:tree:tiger:MMXI5TP5YA2FTWAD4UUA6MQUPC4XPPK3R3I5SFY&xl=18029159&dn=Handbook+of+Object+Technology+(CRC+Press).7z

Обе стоят на закачке который месяц. Нет никого с этими файлами. В поле зрения dc.proisk.org юзеры с такими файлами попадали в начале 2012го года и при мне эти юзеры на хабах так и не появлялись. sci-hub.org не помог. В инете рабочих ссылок не нашёл. При том, что находятся интересные листинги с варезом:
groups.google.com
Очень много в Интернете всяких непонятных лабиринтов типа g5q.ru , где в конце концов попадаешь на поисковик по рапидшарам, но на рапидшаре все ссылки сдохли, либо лабиринтов типа rusbook.net , где в конце концов попадаешь на сайт продавца за много $$$, но перед этим будет обман из ключевых слов Скачать книгу Handbook of Object Technology (Saba Zamir) можно в следующих форматах: rtf.zip, txt, txt.zip, fb2.zip, epub, html.zip, a4.pdf, a6.pdf, java, doc.prc.zip, rb, lit, mobi.prc, lrf, isilo3.pdb.

У меня такое чувство, что я чего–то не улавливаю. У кого–то есть гигантские коллекции книг по программированию и, такое впечатление, ещё и налаженная сеть по распространению этого дела, а в Интернет и DC++ это выплывает по воле случая. Где б надыбать библиотеку программиста, не хуже, чем здесь: groups.google.com Ну и желательно, конечно, с той книжечкой, которую я ищу.

@OCTAGRAM:

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

// Статья стала пропуском на хабрахабр, от кого, не понятно, но и так сойдёт.

@OCTAGRAM:

iis.sinica.edu.tw

Несколько кратких документов о SOM, которые, как мне показалось, неплохо обрисовывают, чем является SOM, что такое метаклассы, несовместимость метаклассов, бинарная совместимость.
Спойлер:
1) Чувак в курсе про CLOS, ObjVLisp, SmallTalk и т. д.
2) В третьем документе презанятная табличка, сравнивающая SOM с другими средствами обеспечения бинарной совместимости между разными релизами. Оказывается, под SGI IRIX есть некий SGI Delta C++, который тоже много, чего умеет

Конечная цель этих инструментов — сделать так, чтобы любые изменения не требующие изменения исходных кодов, не требовали перекомпиляции. То есть, если использовали библиотеку одной версии, и был в ней класс, от которого мы отнаследовались, а в следующей версии этот класс изменился сам и поменял цепочку наследования, SOM или Delta C++ должны избавлять от необходимости перекомпиляции зависимого кода