Ей богу, нападки на CAD-ы совершенно беспочвенны. Помойка, это не особенность некой среды, это состояние души "разработчика"

Читаю структуру dxf-файла (dwg - хоть заобсуждайся, это закрытая структура)
Секции Хэдера и Таблиц отнесем к магическим заклинаниям, без которых невозможно достигнуть (предположим) нужного просветления.
Далее идет секция Блоков.
Фактически, это описание классов. И каждый класс может использовать конкретные реализации (читай - экземпляры класса) уже определенных выше классов.
Со своими индивидуальными св-вами.
Последняя - секция объектов
Собственно, то же самое, что один из классов (по ихнему - блоков) в предыдущей секции (которую можно даже назвать библиотекой, которая необходима именно этому блоку).
Просто там нет точки привязки, или еще чего специального для множественного использование, но именно это и называется конечной схемой.
Тьфу ты, это у нас схема, а у них это объектная модель, чертеж. и т.п..

Собственно и у нас могла бы быть такая же архитектура: сначала идут все SDK в необходимом порядке, а потом собственно схема.
В которой мультики вставляются как и обыкновенные элементы, только имена классов не из палитры элементов, а из вышестоящих секций SDK
И чего-то мне кажется, что такая модель исходника схемы была БЫ более продуманной, чем то, что у нас сегодня есть....
Да, им легче, как-то вопросы рекурсий (линков наверх - по нашему) у них не возникают.
Но в такой архитектуре тоже понятней как разрешать такие вопросы.
Например: сначала определяешь "пустышку", в которой есть только один EditMulti (определяющий интерфейсные точки, и необходимые св-а элемента), последующие мультики используют некий элемент Pointer, которому надо знать только интерфейс, ну и конструктор элемента, аргументами которого является ID класса (или SDK) и необходимые св-ва создаваемого элемента, а уже ниже определение самого мультика, являющегося наследником самой первой "пустышки", но уже нужным содержанием.

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


Далее, заступлюсь и за Слои.
Так снова скажу - очень полезная и нужная вещь. Имеются в виду слои в CAD-овском смысле.
Наблюдал аргументацию, что порой излишняя визуальность не помогает думать глядя на схему, а совсем наоборот.
Если оставить за бортом, что исходной причиной создания технологии-менеджеров было совсем другое, то с самой аргументацией я вынужден согласиться: ДА, иногда хочется прикрыть "лишнее", и работать над схемой без этого.
Ну скажем, схема состоит 25 элементов, и выполняет две важные, но фактически разные задачи.
И разделить схему не получится: 5 элементов принимают участие в обоих задачах. В первой - эти 5, и плюс еще 10, а во второй задаче - эти же 5, но уже плюс другие 10.
И прекрасно Слои справились бы с этой задачей: есть два слоя: общие 5 элементов принадлежат обоим слоям, остальные 20 элементов - по 10 в каждом слое.
Целевая компиляция выполняется при активных обоих слоях.

Кроме "невидимости ненужного", это может обладать и более активной функциональностью.
Например - вариантность схемы. Включил некий дополнительный пользовательский слой (или изменил комбинацию активности слоев) - схема стала обладать дополнительной функциональностью. И ты результаты компиляции передал пользователю, который заплатил больше денег, оставивши функциональность с выключенным слоем для свободного использования.
Это шутка конечно.
Но вариантность иногда очень необходима... А у нас для этого только Check, прошу прощения.
Это и параллельная поддержка отладочных версий со всякими информерами, и т.п.. Да и мало ли чего еще.

Есть еще вопрос про создание своего элемента (который на самом деле мультик), таки визуального, да еще чтобы он правильно в редакторе форм все показывал.
Мне думается, что это определенная часть схемы, имеющая свою локализацию на системном слое типа Draw, которую надо запустить в режиме "интерпретации". Типа отладочного режима, когда запущенная программа имеет связь со средой (собственно, и средства этой связи тоже могут располагаться в слое Draw)
При всем при этом - это не самый тривиальный вопрос, какая именно часть схемы должна в этот слой попасть, для автоматического решения.
Предположим, что пользователь делает что-то похожее по функциональности на TabControl. Ну типа: радиобатонами меняет видимости некоторых контроллов. Ну так пусть этот разработчик своего супер-пупер контролла поместит и логическую часть схемы, меняющую эту видимость в слой Draw - и всего делов. Точнее, добавит активность этих элементов не только целевому слою, но и Draw. Ничего нового рисовать не надо, надо просто птички в нужных местах поставить...

Опять же все правильно получается...
И мне кажется, что настолько правильно, что в профессиональном продукте (т.е., не сегодня), без таких "слоев", как-то даже было бы и не солидно...

Остался скользкий вопрос про "интерпретацию", и что это такое.............................
Тут я знакомился не так давно с технологией языка, как бы 4-го поколения - Forth (остальные язЫки они причисляют к 3-му). Там интерпретация - неотделимая вещь, именно потому что 4-го, и совсем не то же самое, что в "Бэйсиках".
Знакомился не потому, что мне делать было нечего.
А потому, что то, до чего мы дошли не так давно, показалось мне -- они используют лет так 20 уже. Но и у нас есть вещи, до которых они (называющие себя фортерами) еще не доперли.
Когда независимыми путями выходишь на одинаковые (пусть даже в концептуальном смысле) идеи - это хороший признак правильности идей. К сожалению, не более чем признак, но -- все-таки.
За один присест этого всего не расскажешь, но я мог бы выложить попозже "статью" где-нибудь в топике AlexKir-а.
Примерно под таким девизом: "Что такое язык программирования 4-го поколения, является ли HiAsm таковым языком, почему, при всем при этом - Forth находится в з-це, и как нам следует избежать такового"