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

Dilma, это аналоги возможностей предпроцессинга. Или какого-нибудь STL
И никакой визуальности - помнишь же диспуты на этот предмет

НО, это будут элементы разных классов.
И надо делать какое-то различие: если отличаются внешние св-ва - это экземпляры одного класса, а если некое SuperPuper св-во - это автогенерация совсем другого мультика. Т.е., этот SuperPuper стоять должен не в панели св-в, думается...

Хотя если обслужить "перестройку" схемы при входе внутрь контейнера - может с визуальностью все будет не так уж и плохо...
Смотри: обслуживать-то тебе

Но я больше болею за то, что мультик до сих пор не является настоящим элементом
Вот попутно соображение к этому появились (+к тем, что я говорил про "абсолютность" индексов точек предков): нельзя делать наследников от dpe-элементов



[size=-2]------ Добавлено в 14:51
пояснения: кажется более логичным СНАЧАЛА сделать технологию создания кастоящего класса с наследованиями, и ПОСЛЕ этого уже делать библиотеку классов.

ну моя точка зрения прежняя: не вижу смысла в дальнейшем развитие без переделки пакета под честную оптимальную кодогенерацию. Существующая тенденция - все большее раздувание и замедление конечных приложений с каждым нововведением - ну никак не может радовать.

Ну а кто возражает-то.

Вот я излагал логическую схему. Она нужна, чтобы смотреть на нее целиком, а не на пункты по отдельности. Повторю, поэтому:

1) Предположим, что для того, чтобы HiAsm встал в ряд с общеупотребимыми языками программирования - необходимо признание сообщества "продвинутых программеров"

2) Первый пункт возражения - конечность элементной базы для решения любой задачи. Решаем низкоуровневой элементной базой + механизмом контейнеров (с наследованиями, и т.п..). Чем ниже уровень интеграции, тем меньше объем элементной базы.
Ну и для "любых" остаются 2 позиции: рекурсии, и динамические указатели на класс (решаемо, но требует отдельного обсуждения).

3) Но чем ниже этот уровень, тем острей становится вопрос эффективности результирующего кода. Именно для признания. Тестировать правильность решений по 1-му пп. пункту можно и на устойчивой, но неэффективной схеме кодогенерации.

4) Как вывод: ну никуда мы не денемся от создания своего парсера, чтобы объяснить "продвинутому сообществу", что новый класс (элемент) на каждый чих - это совсем не то, что они привыкли видеть в результирующих кодах классических компиляторов (и что интересно - там это их значительно меньше расстраивает, чем в HiAsm).

---

Но получается - не совсем связанные это вопросы, как-бы
Создание возможностей в среде - это круг решаемых задач.
Один прием "ай достаточно прописать" чего стоит.
Функционирование проверяем на имеющейся схеме.
Параллельно - сильно думаем над парсером.
И даже после начала функционирования 4-й версии - должно быть какое-то время совместного существования.
Думается...

---

Вот Вячеслав-то расстроится из-за вопросов совместимости

Не только он, но оно того стоит, наверное. Кроме того никто не запрещает иметь несколько версий.
Про сроки можно не спрашивать?

Можно

Да вообще то нет .
У меня там есть кнопочка Удаление вашего аккаунта вообщем удалить сайт со всем содержимым - это решит все вопросы.

Нет уж умерла так умерла .
А то пять это не работает это не компилируется и т.д.
Да и этот форум начать с нуля надо.

А это еще зачем? Да, это самое простое - Гильотина.

в этом предложение есть определенный смысл. Однако не думаю, что существующий пакет будет заменен. Он станется таким, каким есть - объектная кодогенерация под Object Pascal(Delphi). Новый пакет предпологается сделать под С++ компилятор с использованием собственной функциональной базы. Я думаю, что все будет спроектированно таким образом, чтобы следующим логическим шагом в развитие HiAsm стал переход на Unix подобные системы...

Э, совсем переход, или всё-таки ... расширение функциональности (возможностей) ?
В смысле - по винде будет возможность ездить на хиасме ?

Вот если будет так это значит новая элементная база основанная на других принципах.
А значит всё написанное ранее можно в корзину.

Вот потом там ногу точно сломаешь. Переходим от уровня законченных функциональных микросхем на уровень детальной топологии этих микросхем. Не на уровень слоев (код), но на уровень примитивов -- точно. Да, но у тех кто заимается топологией кристаллов не обычные мониторы, а здоровые экраны, чтобы больше захватить участок обзора. Может Gаlkov'y такое нравится, но это его ИМХО и расчитано на его подготовку. Я себе такое, пока, не представляю, да и рядовому пользователю, пойдет ли -- не могу сказать. Коды -- это одно, а схемы -- совсем другое. ИМХО.

Ну блин
Нельзя же быть таким простым, как сибирский валенок
И понимать все абсолютно буквально

Это просто ЛОГИКА.

1) Есть логическое утверждение, требующее опровержения, что


2) Для опровержения "НЕ существует" достаточно привести пример такой базы. Пожалуйста: процессор имеет конечное число команд. Каждую команду мы МОЖЕМ оформить в виде элемента, и соединить их так, чтобы реализовать любой наперед заданный код.

3) В том числе и коды существующих сегодня элементов, если приложим достаточно труда для модернизации нашего интерфейса структуризации и наследования.
Т.е., эта часть является тоже существенно необходимой.

---

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

Просто у нас должна быть возможность делать элементы на HiAsm - мы должны уметь придавать мультикам все характеристики нормальных элементов.
Внутрь которых нет необходимости заглядывать (если есть боязнь сломать ногу).
Но возможно, как возможно и заглянуть в паскаль-коды сегодняшних элементов. Просто язык другой: там паскаль, а тут HiAsm - вот и все.

Но при такой идеологии эффективность результирующего кода становится не просто проблемой - она вырастает до кошмарного размера.

Так ее надо просто решать - и всего делов.
Вот задача более важная и нужная, чем слияние кучи функциональностей в один элемент, и обзыванием этого всего "мультипроцессором"

Я думаю сделают её не раньше, чем придумают физическую реализацию бесконечной ячейки памяти...


это утверждение верно и для языка: каждый язык имеет ограниченное число инструкций. поэтому можно сделать элементную базу такую, что она позволит решить абсолютно любую задачу, которую позволяет решать данный язык. Проблема только в том, что компонент hiAsm написанный не в кодах, а с применением такой базы перестает быть переносимым.

Я как-то не против запихивания элементов в мультик. Часть схем так и построена. Меня волнует не возможность создания такого мультика, а его отладка с примеением существующего графического интерфейса. Хотя, во всем этом, что-то есть... тут про это уже Вячеслав писал, правда для Delphi.
А что (это я про себя)-- создать модульную таблицу на микроэлементах, заманчиво.
У меня стиль такой. Я иногда выступаю в роли оппонента, и задаю такие вопросы, виртуально не от себя, а как если бы его задали другие.
P.S. Я не рассматривал технические реализации, я только пытался глубже въехать в концепцию.