← All posts tagged CLOS

OCTAGRAM
web JavaScript CLOS SOM А было бы кому–нибудь интересно, если бы я реализовал SOM для JavaScript? Множественное наследование, как в CLOS, метаклассы.

Для тех, кто не знает, в чём разница между множественным наследованием, как в CLOS, и как, например, в C++ (и некоторых других JavaScript библиотечках, которые я тут посмотрел на тему МН):
В C++ для вызова родительского метода он указывается по имени родительского класса. Два родителя — делай два родительских вызова или ещё как–нибудь. Или делай только один из них, и однажды это запорет систему. Или не делай ни одного, но не знающий об этом программист другого компонента может сделать ромб в структуре классов и, чтобы не вызывать код дважды, вызовет только метод твоего класса, и всё запорется. Пример:
// Call the super constructors of the base classes.
Person.call( this, "Ben" );
Monkey.call( this, true );

Для сравнения: в CLOS и SOM родительский вызов — это специальная форма вызова, в которой имя родителя НЕ указывается. В DTS C++ в том виде, как он описан в «Putting Metaclasses to Work», пришлось добавить синтаксис __parent->method(). Так называемые кооперативные методы, будучи переопределены, ОБЯЗАНЫ вызвать родительский метод, за исключением случаев вроде такого, когда цепочка вызова методов образует коньюнкцию или дизъюнкцию, и нам попался false или true, соответственно. Для каждого класса все его родители выстраиваются в упорядоченный список (class precedence list в CLOS, method resolution order в SOM), и семантика вызова родительского метода — это, на самом деле, вызвать реализацию из предъидущего по списку класса, который в случае наследования ромбом может быть более левым родителем дочернего класса, или ещё где–нибудь. Некооперативные методы можно писать иначе, но компилятор потом может запретить наследование из–за потенциального конфликта. Впрочем, в собственно SOM я не видел проверок на кооперативность и я не видел таких пометок у методов, так что некооперативными методами (не вызывающими родителя или вызывающими конкретного родителя/родителей), как я понимаю, при желании всё–таки можно что–нибудь запороть.

За основу можно взять Java–симуляцию, которая прилагалась к книге: bitbucket.org
OCTAGRAM
programming ООП CLOS SOM iis.sinica.edu.tw

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

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