Данный топик предлагает вам базу для рассуждений всевозможных предложений по среде HiAsm.

---

1. А почему бы не добавить в компоненты HiAsm поддержку версий? Это сделает возможным одному имени компонента давать разные реализации с разными наборами точек и функциональностью. Проблема совместимости уйдет на второй план.
Как предполагается работа? В sha-формате в список свойств добавить свойство @Version типа float. В ini-файл добавлять для каждой версии свои секции с номером версии:

При загрузке схемы среда считывает поле @Version и загружает данные из нужной секции ini, дальше как обычно.
Если версия отсутствует, выдается ошибка.

2. А почему бы не добавить новый формат конфига компонентов?
Как предлагал iarspider, xml. Добавить в качестве основного, но с поддержкой старого ini. Среда при загрузке схемы будет сначала искать xml-версию конфига, если отсутствует, то ini. xml позволит еще проще реализовать п.1 и даст кучу других плюшек.

Спасибо за внимание.

P.S: хорошо я урок геометрии сижу

1. Может ТС имел в виду принцип форков от основного исходника? Если да, то подстегнёт рост размера среды и SVN из-за кучи дубликатов компонентов, отличающихся парой точек. И без того путаница, а будет ещё хуже.
2. XML трудно редактировать вручную, неоправданные расходы на редакторы и обработку конструктором, как по коду, так и по скорости. Имеет смысл только если уже стоит быстрый XML-движок, активно использующийся в остальных местах среды.

Assasin, идея хорошая! А ещё хотелось-бы структуру папок улучшить, например так, для каждого компонента создать отдельную папку и туда кидать и иконки и версии компонентов и ini и xml а не как сейчас, очень сложно найти нужный компонент и его файл конфигурации, и очень неудобно!

1nd1g0,
2. Как это трудно? Не труднее, чем html. А парсинг конфига будет проводиться при первой встрече компонента в среде, парсится и заносится в память распарсенная версия для ускорения загрузки в дальнейшем.

Тогда нужен нормальный визуальный редактор компонентов, а не блокнотоподобное нечто. Если уж вводить XML, то можно и новым форматом схем его сделать, и код компонента объединить с ini в одном XML, т.к. файлы целевого языка использоваться больше не будут, а кодогенератору через общий для среды движок XML удобнее будет рыться в иерархических структурах схемы.

Assasin, HiAsm продвигается, но потом на форуме Assasin будет спрашивать: "Ребята, как, блин, в треугольнике угол определить?!"

Для того и форум, что-бы спрашивать! А мы ему подскажем!

Леонид, в 11-ом классе должно быть стыдно подобные вопросы задавать
------------ Дoбавленo в 11.06:
1nd1g0, угу, это была моя третья идея - все в одном файле.

И я свои 5 копеек вставлю.
1) Пакеты среды должны быть абсолютно равноправны. Не должно быть возможностей, специально заточеннных под отдельный пакет.
2) Сделать более универсальный интерфейс редакторов свойств. Редактор должен быть dll-кой с полным доступом ко всем свойствам данного компонента (а возможно, и любого другого), иметь набор callback-методов для реагирования на изменение любого свойства, а также изменять любые свойства компонента, а не только то, для которого был вызван. Ну, или усовершенствовать пакет Modules.
3) Каждый поддерживаемый средой тип свойств должен быть описан публичными интерфейсами, чтобы любой кодогенератор имел к ним прямой доступ. Сейчас многие типы свойств заточены под пакет Delphi.
4) Добавить команду "Внедрить в схему" - при щелчке на компоненте в схеме выбирается эта команда, и компонет с его конфигурацией и кодом помещается в файле схемы. Иконка такого компонента может получать какую-то отметку. При компиляции компонент извлекается из схемы, схема компилируется, компонент удаляется. Поможет решить проблему нестандартных компонентов.
5) В конфигурации компонента добавить возможность локализации, возможность указывать, для каких типов проектов этот компонент будет доступен/недоступен.

Netspirit, как я понял, предлагается сделать каждый элемент возможным в применении в других пакетах?

ini XML (конфигурация)
+
hws XML (исходный код)
+
svg XML (векторная иконка)
=
XML
------------ Дoбавленo в 12.08:
Ну и, естественно, если
sha XML
+
компоненты XML
=
sha со внедрёнными компонентами (т.е. файл "проекта")

1nd1g0, да, именно это xml вообще очень удобный формат, только надо сделать, как ты уже подметил, удобную и быструю работу с ним.

Assasin, не вижу смысла. В схеме стоит метка пакета, соответственно, компонент относится к тому же пакету. Или ты это о п.5? Имелось в виду, что при создании, например, консольного приложения, интерфейсные элементы не отображались бы в палитре компонентов.

А XML лично мне не очень нравится. Возможно я ещё не представил себе всех прелестей его внедрения. А hws на XML - как можно FTCG код представить в XML?

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

Что 3.14здец, то 3.14здец.
А я другие вопросы задам (вернее задайте их себе):
Перечислите пожалуйста по пунктам (для себя, а можете выложить и сюда)
1. Достоинства применения xml
2. Недостатки применения xml
3. Достоинства применения txt
4. Недостатки применения txt
5. В чем преимущество xml перед txt (для пакетов HiAsm)
6. Что даст замена txt на xml (про 10-кратное увеличение ini-файлов писать не надо).