Может и буквально, но:
1) без однозначности понимания - я читаю топики подробно, а не "видишь толко то, что хочешь видеть"
2) не совсем в ту тему, которая уже была начата.

Но можно обсуждать и это, хотя это другой вопрос

1) Если мультики нарисованы механическим напихиванием туда элементов - разобраться действительно будет сложно

2) А вот если организовывать объекты по функциональности - абсолютно другая история. Исходя из того простого принципа: понимание и функционирование схемы НЕ ДОЛЖНО зависеть от конкретного наполнения мультиков схемы. Схема должна функционировать ТОЧНО ТАК ЖЕ, если мультик сделает совсем другой человек, и ты вообще не знаешь что там внутри.
А в комменте к нему стоит полное "техническое задание" на его разработку, к примеру.

3) Вот именно это и называется ООП, а не тупое повторение заклинания "инкапсуляция, наследование, полиморфизм"

4) И, кстати, сколько строк программы на "скриптовом" языке помещается на твоем не резиновом мониторе ???

Не много, согласен, но я вижу обращение к конкретому методу, а не линк, уходящий в небытие. И еще, методы хоть как-то обозваны, и я знаю, что каждый делает, что не могу сказать о компонентах. Ценность схемопостроения именно в том, что видеть схему целиком со всеми компонентами и линками. Но это ИМХО.

nesco, все зависит от пишущего. В нашем случае рисующего. Что мешает на каждый мультик написать подробнейшую справку - Что,Где,Когда. ? И даже на каждую точку мультика пиши-нехочу. Даже если пишешь для себя.
Ответа два -
1- лень,
2-отсутствие культуры програмирования.
Третьего не дано

я думаю стоит еще вернуть назад навигатор по схеме из второй версии HiAsm(если конечно кто еще помнит о таком). Всетаки при наличие в проекте большого числа контейнеров он бывает очень полезен.

Не видел такого, но мысль интересная.Да причем здесь мультики? Каждый мыслит по-своему. Если я представляю схему целиком в 3D проекции, то другой может представлять совсем по-другому. Естественно, мне будет тяжело, если я не буду видеть всю схему, а еще тяжелее, если не буду видеть внутренности мультиков (особенно, если их много). Мне проще создать мультиформатный процессорный компонент с минимальной обвязкой и знать, что конкретно делает каждый его метод, чем лепить вместо него 1000 компонентов. ИМХО.

Глупость несусветная.
К HiAsm никакого отношения не имеющая - это на 100%

http://x-worms.narod.ru/hiasm/hiasm_.rar


Создать всмысле в коде реализовать?

И беда твоя в том, что ты мыслишь "по своему"
А надо так, чтобы НЕ БЫЛО необходимости видеть внутренности мультиков.
Если у тебя есть - ты делаешь все неправильно.
И далеко не уедешь

И даже НЕ буду говорить ИМХО

И почему же, не имеющая?
Galkov, я до сих пор не могу тебя понять, что ты лоббируешь? Какую концепцию? Тебя послушать -- много элементов -- это хорошо, это -- просто отлично. Значит вы умеете ими пользоваться, умеете их применять.но я же не сказал на чем, это может быть и обычный мультик, хорошо отлаженный. Но, к сожалению, не все можно выполнить на штатных компонентах, далеко не все.

[size=-2]------ Добавлено в 19:29

Что есть? Я не понял.

необходимость видеть внутренности мультиков

Хорошо, задам вопрос Dilme. Что мешает помимо шаблонов ввести метод -- Сделать Компонент? Отладил мультик (хорошо бы, чтобы еще и контролы поддерживал), вставил иконку, описал точки, и... превратил в компонент. И вставляться в сехему он должен не как шаблонный мультик, а как компонент.

[size=-2]------ Добавлено в 20:19

Но мультики разные бывают. Есть типовые, а есть и оригинальные, в которые запихиваешь мешающие на схеме компоненты. А если завтра захотелось поменять конфигурацию оригинального мультика?
Tad, а ты забыл, что недавно сказал про пример Dilmы с базой? И что, нет необходимости видеть их внутренности, хотя бы для понимания -- как это работает?

а как компонент это как?

Зачем внутренности? Хватает коммента, который иконку ставит.. а так не туда, ни сюда, что ты увидишь в десяти пикселах?

Dilma, я имел в виду -- как обычный элемент палитры. Со своим ini-файлом, взятым из описания точек, со своей иконкой, взятой из иконки ##main, со своим pas-файлом, полученным после генерации, и, желательно, с убранными межкомпонентными связями.

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

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