• 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

Replies (13)

  • @OCTAGRAM, У тебя либо сом, либо коб.
  • @mabu, Зато ни у кого другого нет про SOM
  • @OCTAGRAM, Похоже, что он настолько не нужен, что ты сам его не используешь.
  • @mabu, Эта штука ещё не в таком состоянии, чтобы я мог её использовать, но для неё это состояние хотя бы достижимо
  • @OCTAGRAM, Ты что, сам её будешь допиливать, что ли
  • @mabu, Именно
  • @OCTAGRAM, И внедрять во все операционные системы?
  • @mabu, Если интегрировать с Wine и виртуализаторами x86 на платформах с другими архитектурами, будет этакий аналог JVM для нативных языков
  • @OCTAGRAM, Опять эти виртуальные машины? Чем тебе дотнет не угодил с, простите боги, явой?
  • @mabu, Сборкой мусора, плохой объектной моделью и тем, что Delphi, Ada и C++ в него толком не научились нормально компилироваться. А ещё я вижу, что даже для JavaScript то NaCl сделают, то FlasCC, то Asm.js, и я так понимаю, некоторая востребованность имеется.
  • @OCTAGRAM, Что‐то Мне уже не нравятся все эти интерпретаторы со сборками мусора. Пишу на фрибейсике без RTL, память нужно выделять и освобождать самостоятельно, чувствую полный контроль за временем жизни объектов. А ещё объекты можно создавать прямо в стэке, что просто замечательно.
  • @mabu, Ну вот спроси у разработчиков ДубльГИС, почему их несчастный софт для отображения карты написан не на Java или .NET, и его приходится выполнять на Wine. Но он хотя бы под Wine как–то заточен.

    Я не вижу, чтобы скрипты и клоны джавы были способны охватить всё многообразие хотя бы прикладного софта. Значит, чтобы отвязаться от Windows, нам нужно предоставить кроссплатформенную среду исполнения для программ на языках, компилируемых в машинные коды. И вот тогда — вендекапец.
  • @OCTAGRAM, Не наступит, есть же ReactOS.