вообще, любопытно было бы прикрутить SOM к Vala или D.

Vala: простой ООП язык с моделью GObject. SOM даст бинарную совместимость, которая не ломается.

D: на тему сравнения С++ vs. SOM. есть ощущение, что из SOM и C++ можно сделать некоторую общую метамодель (назовём её к примеру, zOM). модель, частными случаями которой будет как SOM, так и C++ VTable VMT VPTR. а умным CTFE метапрограммированием делать ту часть, которая в SOM делается в рантайме.

объектные брокеры сосут, а метапрограммирование спасёт нас

идея SOM: быть универсальной объектной моделью системы. то есть, поскольку у нас может быть ООП в стиле смоллтока или в стиле С++ или вообще на Си — объектная модель должна быть надмножеством, обладая возможностями и смоллтока, и плюсов, и неплюсов. поскольку общего ABI на С++ нет — раскладка полей класса компиляторозависимая, будем задавать раскладку руками, в IDL releaseorder. поскольку API должен быть бинарно совместимым, он должен быть на «плоском си». поскольку такая часть, как работа с типами, метаклассами, диспетчеризация — окончательно известна только в рантайме, вытащим в рантайм всё, а вместо указателей на метод в VPTR сделаем хак, указатель в ClassDataObject, MethodToken, которые будут заполняться «в конструкторе» (как он выглядит на плоском си апи, т.е. метод метакласса). отсюда же IDL, разработка метапрограммированием на IDL компиляторе + компиляторе языка + макросы

я думаю, что можно поступиться некоторой универсализацией. например, сделать некоторую ООП модель («zOM») универсальную только между C++ и D, например, а не унивесальную между всеми, любыми языками. а ту часть SOM, которая делается в рантайме — максимально вытащить в compile time, через CTFE функции.

в итоге сделать «почти С++ VTable» модель, но разработанную обратным способом, из общей объектной метамодели.

та часть, которая в SOM делается в runtime — будет делаться мегаумным метакомпилятором, с точки зрения которого разные calling conventions, раскладки объектов в памяти и т.п. будут выглядеть одинаково, унифицированно.

предполагается, что такая zOM модель сможет выдавать более лучшие бенчмарки, чем SOM vs. C++ vs. zOM за счёт метапрограммирования времени компиляции, и более низкоуровнего ABI.

соответственно, специализациями этой метамодели будут реализации COM, SOM, C++ VTable VMT, D ООП модель, Vala GObject ООП модель, и т.п.

их надо будет строить метапрограммированием из общей «метамодели zOM», максимально разгружая всё в CTFE функции времени компиляции. пока не получим что-то вроде минимального подмножества необходимой пары объектных моделей.

ссылка

баунти под eCS

на openwatcom под полуось вроде просто выглядит

патентные трололо такие трололо

Patents Constructor based object initialization with overrides Object oriented framework for specifying the format of compiler output with a template facility System and method for enabling before/after method processing in an object oriented system Object oriented framework for creating new emitters for a compiler Template based facility for formatting compiler output Method and system for logical event management

откровения капитана очевидность

возьмём к примеру, Qt, и посмотрим внимательно, как оно устроено.

программы для Qt пишутся на каком-то метаязыке Qt/C++, который поддерживает слоты и сигналы, рефлексию и интроспекцию. утилита moc транслирует этот Qt/C++ в «обычный» C++, который затем собирается обычным С++ компилятором, с объектной моделью VTable/VMT.

утилита написана как препроцессор, который «компилирует в С++», но это всего лишь «особенности реализации».

вполне мог бы быть написан и какой-то Qt-«Direct-to-SOM» компилятор: сигналы и слоты могли бы быть реализованы как метод метакласса соответствующего QObject, к примеру.

тогда вместо «компиляции в С++» Qt можно было бы разделить на две части: Qt-to-SOM и SOM-to-C++. при этом автоматически вместе с SOM-to-C++ получили бы и остальные привязки SOM-to-XXX.

метапрограмирование спасёт нас здесь: например, при переходе от Qt4 к Qt5 исходники были трансформированы для поддержки C++11, не только вручную но и утилитой на базе clang (см. бложик qtlabs)

подумаем немного, как такая утилита могла бы быть написана.

сейчас порядок разработки на SOM такой:

IDL -> (sc, som compiler) -> h,ih,cpp -> (cc + ilink) -> приложение + somtk.dll

порядок разработки на Qt примерно такой:

moc -> h,cpp -> ( *.ui, переводы, ресурсы ) -> (qmake/qbs) -> (cc + link) => приложение + набор QtXXX.so

а что, если бы вдруг появился какой-то другой «обратный метакомпилятор», который из ООП языка С++ (в варианте Qt) генерировал аналогичные конструкции для SOM?

просто тупо построчно переводил бы все аналогичные конструкции Qt/C++ в конструкции SOM. в итоге по C++ модели автоматически строилась бы модель SOM объектов.

затем, можно было сделать какую-то оптимизацию, скажем, делать соответствие не 1:1 C++ объект к SOM объекту, а 1:M.

или, вспомнив, что исходный язык — не голый С++, а метаязык Qt/C++ — добавить нужные оптимизации в метаязык, N:M.

то есть: то, что делают совместно moc и C++ VMT/VTable модель — это ведь просто оптимизация этого «метакомпилятора», отображение объектной модели некоторого языка Qt на объектную модель С++, которое оказалось простым.

в SOM такое отображение можно делать через метаклассы.

в других, чем C++ языках и объектных моделях вполне может оказаться более оптимальным другое отображение, другое API.

а само подобное API можно было бы генерировать каким-то метапрограммированием, не сильно ограничиваясь в выборе доступного языка (вроде С++).

немного профита может дать и такой порядок:

old C++ «native objects» -> IDL -> Som Objects -> new C++ SOM -> ...

чтобы достаточно умный компилятор языка (С++, например) сам умел генерировать IDL из исходника.

например, в языке D такой «метакомпилятор» вполне можно реализовать CTFE функциями.

вот есть например, QtD — биндинги. были написаны частично портированием QtJambi, биндингов к Java: переделана утилита, которая делает биндинги к Java к реалиям D.

В итоге, имеем врапперы: объектный D обёрнут «плоским» Си враппером, который связан с мостом плоским Си враппером к С++. обёртки, копирование туда-сюда параметров (маршалинг), дублирование кода : код утраивается (код моста Д-Си, код обёртки Си-С++, сам код на с++).

сам moc в QtD реализован не отдельной утилитой, а библиотечной функцией.

предположим, у нас был бы какой-то похаканный clang, который умел бы генерить IDL из С++ исходника, и напускать на него Som Compiler.

тогда можно было бы из С++ объектов эту модель вытащить и отобразить на SOM объекты.

то есть, тезис таков: в дополнение к «объектному линкеру», про который было написано где-то у тебя на сайте, полезен был бы и объектный компилятор, объектный оптимизатор.

который бы позволял выбирать, реализовать ли какую-то систему объектов как компоненты универсальной SOM, к примеру, или как «cплошные» native C++ объекты.

native C++ объекты — это результат «объектного компилятора», оптимизатора в какую-то конкретную объектную модель.

идея SOM — что такая объектная модель может быть универсальна

идея ООП языка ХХХ — что его объектная модель может быть более оптимальна

т.е., «родные объекты» можно было бы разобрать на некоторые «универсальные» объекты, и затем, «оптимизировать» в некоторую другую (более оптимальную?) объектную модель, другого языка

кстати, и про автоматическую генерацию привязок к Си. семантику строк, например, и т.п. (in, out, result) — чего не ясно из си хедеров.

на сайте llvm есть публикация (вот pdf), как привязки к си можно генерировать автоматически статическим анализом.

поинт в том, что нужно что-то более умное, чем тупой препроцессор, чтобы понять смысл используемого в API параметра (головой, или стат. анализом)

для сравнения: вот как генерируются биндинги в Vala через GObject Introspection

интересно было бы сопоставить с SOM.

возможно ли делать биндинги к SOM похожим с точки зрения workflow способом.

вообще, интересны след. направления развития:

1. открытый SOM, который без проблем собирается современными компиляторами: gcc и clang, (? Visual Studio), возможно openwatcom ( под полуось с livecd можно будет проверить эту реализацию и сравнить с системной). открытый анало SOM compiler.

2. приспособить эту открытую SOM модель к языку Vala например. Vala простой язык c синтаксисом, похожим C# (есть genie, с синтаксисом, похожим на питон) для объектной модели GObject. код на Vala транслируется в си, собирается си компилятором. к примеру, есть сборка под винду, на GTK3.

любопытно было бы взглянуть на то, как можно автоматизировать создание биндингов для SOM + примеры Vala/SOM в сравнении с Vala/Gobject.

3. D, привязки к SOM, мост SOM-to-COM, CTFE метапрограммирование.

в D уже есть простая прозрачная интеграция с Си; под виндой есть поддержка COM, можно писать клиенты и серверы.

интересны:

а) привязки D-to-SOM.

б) привязки к COM, реализованные поверх SOM. насколько этот велосипед будет тормозить. насколько его можно упростить метапрограммированием.

в) описанный выше «метакомпилятор» объектных моделей. допустим, нужно связать два языка, D и X. выбираем описание на метаязыке объектных моделей D-to-SOM, SOM-to-X, и оптимизируем его, вынося всё, что можно вычислить во время компиляции.

получаем «идеальную объектную модель» для этой пары языков, сферическую и в вакууме.

ещё любопытно посмотреть на аналог GObjectIntrospection для SOM

точнее, хочется типа такого туториала, но для SOM

или такого

сборка Vala под винду, на GTK3.

более свежая ссылка

разработка OpenGL чайника на FreeGLUT под Vala — подробный туториал с картинками

топикстартер, вот чего-то подобного хочется по примерам разработки на SOM: скачать библиотеки, настроить среду, сделать все настройки из коробки до готового продукта (то есть, поделки)

лулзота. часть 1 часть 2

Testing was a concept Microsoft struggled with

Testing OS/2 was a concept Microsoft struggled with at the time. More than once I had to deal with Redmond code that was reported to have passed and failed various quality assurance tests with complex behaviours, yet for some reason that code consisted solely of a RETF instruction, which (in theory) simply ends a subroutine call.

Their code reviews were a joke. Their developers put source code comments of the form “Skip over random IBM NLS shit” in the support for national languages, and the comment “if window count is zero return false” was next to a line that always returned zero. Microsoft flatly refused to fix this one saying that it conformed to Redmond's coding standards, a copy of which we never managed to acquire if it actually existed.

We, on the other hand, were regarded as hopelessly bureaucratic. After Microsoft lost the source code for the actual build of OS/2 we shipped, I reported a bug triggered when you double-clicked on Chkdsk twice: the program would fire up twice and both would try to fix the disk at the same time, causing corruption. I noted that this “may not be consistent with the user's goals as he sees them at this time”. This was labelled a user error, and some guy called Ballmer questioned why I had this “obsession” with perfect code.

юзаюбилити тестинг на девелоперс, девелоперс, девелоперс, девелоперс...

In spite of this, OS/2 was easier to program than anything else you could find. We knew this for a fact and buried somewhere in IBM are the videos to prove it. IBM hired in skilled programmers from every platform and asked them to carry out various programming tasks in the usability lab and they took longer than they should have.

The problem was that the developers kept on asking “how do I do X” where X was some hack or workaround you didn’t need to do in OS/2. Mac and Windows developers actually seemed quite angry that so many of their favourite kludges were not needed.

статьи про устройство SOM на русском

йес, обхс: директикс под Vala

осталось только узнать, когда же кто-нибудь додумается интегрировать GObject с COM API.

Меня просто тошнит от того, чем считает нормальным быть open source. Отношение к компилируемым программам как к скриптам. C++ вместо объектной модели с привязкой к компилятору. ./configure --with, ./configure --without, и прочая ересь. Когда я слышу «open source», я представляю себе что–то такое же, как закрытое, только лучше, а на деле такого правильного open source'а очень мало. В гробу я видел эти --with и --without.

механизм самоуничтожения под названием GPL уничтожает люникс

«A pile of old festering hacks, endlessly copied and pasted by a clueless generation of IT 'professionals' who wouldn't recognise sound IT architecture if you hit them over the head with it,» was Kamp's summary of the bazaar model after laying into baffling tool autoconf.

tr;dr

механизм самоуничтожения под названием GPL уничтожает люникс

Meanwhile, the IBM PC was quietly taking over, growing in power and capabilities. IBM had crippled its OS/2 product by mandating that it ran on Intel's 286 processor. This was a chip that hamstrung an operating system's ability to multitask existing DOS programs - even though OS/2 came out after Intel introduced the superior 386 processor, which could easily handle multiple «real mode» DOS apps.

моя негодуэ. читаем предыдущую ссылку про удачно женившегося контрактора, который фиксил баги для ИБМ, про версию OS/2 1.3.

иначе как вредительством такое «манагерство» и не назовёшь.

ещё интересная объектная система: COS, на реализована на обычном Си.