Чтобы добавлять сообщения и комментарии, .

@OCTAGRAM:
OCTAGRAM

А было бы кому–нибудь интересно, если бы я реализовал 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

@Sectoid:
Sectoid

и вот еще странного порою хочется: хочется для generic'а задавать более одной :before, :after и :around специализации (для одинакового набора аргументов, хочется чтобы они просто вызывались все, по очереди). Есть способы это сделать? Или я чего-то не знаю?)

@lovesan:
lovesan

В очередной раз услышал о том, как де в лиспе неудобно обращаться к данным объектов/структур(префиксы длинные, через точку нельзя, бла бла)

Поэтому решил написать, почему данные претензии неадекватны.

love5an.livejournal.com

@OCTAGRAM:
OCTAGRAM

iis.sinica.edu.tw

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

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

@lovesan:
lovesan

У меня слёзы на глаза наворачиваются когда в языках с "обычным" ООП мне приходится городить Visitor'ы.

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

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

И ладно бы язык, при работе с которым это всё возникало, был бы Java или C#, так нет, я говорю — вся модная, в том числе динамическая, хипстота — а туда же.

@lovesan:
lovesan

Меня серьезно интересует данный вопрос на самом деле.

Неужели имплементоры всех этих новомодных языков на самом деле такие малограмотные дебилы?

Java и всякие C# лесом идут — они то как раз намеренно для дебилов и создавались, особенно первый. А вот то что сегодня модно?

@lovesan:
lovesan

Почему за столько лет существования CLOS она просочилась только как максимум в варианты Scheme и в другие диалекты лиспа(от Dylan до, местами, Clojure — хотя в последнем всё очень упрощено, если не сказать удебилено).

Почему ни один мейнстримный язык не прикрутил к себе охуенную ОО-систему подобную CLOS? Ладно Java какая-нибудь, но вот прогрессивная хипстота, типа Ruby, или вон Scala какая-нибудь — а всё туда же, ООП как в 60х, как в Simula.

@bioh:
bioh

Common Lisp Object System, which was formally accepted by X3J13 in June 1988
Это ведь единственный и актуальный на данный момент станадрт по CLOS?

@Crazy-Owl:
Crazy-Owl

А вот скажите, можно ли как-нибудь помочь generic functions диспетчиться в рантайме, если знаю, к какому классу принадлежит значение, которое туда передается? И окажет ли это влияние на скорость диспетчинга? Кто-нибудь замерял этот вопрос вообще?

@lispnik:
lispnik

Перевёл статью Натана Фройда "Протокол инициализации CLOS": lispnik.livejournal.com