Вверх ↑
Этот топик читают: Гость
Разработчик
Ответов: 4690
Рейтинг: 425
#1: 2012-04-06 10:25:21 ЛС | профиль | цитата
Данный топик предлагает вам базу для рассуждений всевозможных предложений по среде HiAsm.


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

[version1.0]
Code=component1.0.pas
Один набор свойств и точек

[version1.1]
code=component1.1.pas
Другой набор

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

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

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

P.S: хорошо я урок геометрии сижу
карма: 10
0
vip
#1.1контекстная реклама от партнеров
Ответов: 3889
Рейтинг: 362
#2: 2012-04-06 10:36:57 ЛС | профиль | цитата
1. Может ТС имел в виду принцип форков от основного исходника? Если да, то подстегнёт рост размера среды и SVN из-за кучи дубликатов компонентов, отличающихся парой точек. И без того путаница, а будет ещё хуже.
2. XML трудно редактировать вручную, неоправданные расходы на редакторы и обработку конструктором, как по коду, так и по скорости. Имеет смысл только если уже стоит быстрый XML-движок, активно использующийся в остальных местах среды.
карма: 1

0
Ответов: 1061
Рейтинг: 22
#3: 2012-04-06 10:37:25 ЛС | профиль | цитата
Assasin, идея хорошая! А ещё хотелось-бы структуру папок улучшить, например так, для каждого компонента создать отдельную папку и туда кидать и иконки и версии компонентов и ini и xml а не как сейчас, очень сложно найти нужный компонент и его файл конфигурации, и очень неудобно!
карма: 0

0
Разработчик
Ответов: 4690
Рейтинг: 425
#4: 2012-04-06 10:43:35 ЛС | профиль | цитата
1nd1g0,
2. Как это трудно? Не труднее, чем html. А парсинг конфига будет проводиться при первой встрече компонента в среде, парсится и заносится в память распарсенная версия для ускорения загрузки в дальнейшем.
карма: 10
0
Ответов: 3889
Рейтинг: 362
#5: 2012-04-06 10:57:10 ЛС | профиль | цитата
Тогда нужен нормальный визуальный редактор компонентов, а не блокнотоподобное нечто. Если уж вводить XML, то можно и новым форматом схем его сделать, и код компонента объединить с ini в одном XML, т.к. файлы целевого языка использоваться больше не будут, а кодогенератору через общий для среды движок XML удобнее будет рыться в иерархических структурах схемы.
карма: 1

0
Ответов: 8695
Рейтинг: 806
#6: 2012-04-06 10:58:07 ЛС | профиль | цитата
Assasin, HiAsm продвигается, но потом на форуме Assasin будет спрашивать: "Ребята, как, блин, в треугольнике угол определить?!"
карма: 19

0
Ответов: 1061
Рейтинг: 22
#7: 2012-04-06 11:00:24 ЛС | профиль | цитата
Леонид писал(а):
но потом на форуме Assasin будет спрашивать: "Ребята, как, блин, в треугольнике угол определить?!"

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

0
Разработчик
Ответов: 4690
Рейтинг: 425
#8: 2012-04-06 11:06:52 ЛС | профиль | цитата
Леонид, в 11-ом классе должно быть стыдно подобные вопросы задавать
------------ Дoбавленo в 11.06:
1nd1g0, угу, это была моя третья идея - все в одном файле.
карма: 10
0
Ответов: 4476
Рейтинг: 716
#9: 2012-04-06 11:48:29 ЛС | профиль | цитата
И я свои 5 копеек вставлю.
1) Пакеты среды должны быть абсолютно равноправны. Не должно быть возможностей, специально заточеннных под отдельный пакет.
2) Сделать более универсальный интерфейс редакторов свойств. Редактор должен быть dll-кой с полным доступом ко всем свойствам данного компонента (а возможно, и любого другого), иметь набор callback-методов для реагирования на изменение любого свойства, а также изменять любые свойства компонента, а не только то, для которого был вызван. Ну, или усовершенствовать пакет Modules.
3) Каждый поддерживаемый средой тип свойств должен быть описан публичными интерфейсами, чтобы любой кодогенератор имел к ним прямой доступ. Сейчас многие типы свойств заточены под пакет Delphi.
4) Добавить команду "Внедрить в схему" - при щелчке на компоненте в схеме выбирается эта команда, и компонет с его конфигурацией и кодом помещается в файле схемы. Иконка такого компонента может получать какую-то отметку. При компиляции компонент извлекается из схемы, схема компилируется, компонент удаляется. Поможет решить проблему нестандартных компонентов.
5) В конфигурации компонента добавить возможность локализации, возможность указывать, для каких типов проектов этот компонент будет доступен/недоступен.
карма: 26

0
Разработчик
Ответов: 4690
Рейтинг: 425
#10: 2012-04-06 12:03:03 ЛС | профиль | цитата
Netspirit, как я понял, предлагается сделать каждый элемент возможным в применении в других пакетах?
карма: 10
0
Ответов: 3889
Рейтинг: 362
#11: 2012-04-06 12:08:34 ЛС | профиль | цитата
Assasin писал(а):
моя третья идея - все в одном файле

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

0
Разработчик
Ответов: 4690
Рейтинг: 425
#12: 2012-04-06 12:13:03 ЛС | профиль | цитата
1nd1g0, да, именно это xml вообще очень удобный формат, только надо сделать, как ты уже подметил, удобную и быструю работу с ним.
карма: 10
0
Ответов: 4476
Рейтинг: 716
#13: 2012-04-06 12:25:24 ЛС | профиль | цитата
Assasin писал(а):
каждый элемент возможным в применении в других пакетах

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

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

0
Разработчик
Ответов: 25687
Рейтинг: 2088
#14: 2012-04-06 12:41:08 ЛС | профиль | цитата
Ну, пи@дец -- даются предложения катастрофически усложняющие жизнь разработчикам. XML уже выдумали для компонентов. Вы, я стесняюсь спросить, какую траву курите, прямые поставки, наверное
Если обычный текст компонента можно просмотреть в обычном блокноте, то XML компоненты надо будет смотреть только в среде. Вопрос -- а на кой хрен это надо А кодогенератору какая нагрузка -- распарсить сначала XML, затем распарсить полученный скрипт, потом сгенерировать из него целевой код. По вашим предложениям и sha можно в XML преобразовать. Все в него, чего уж мелочиться-то
карма: 20

0
Ответов: 16884
Рейтинг: 1237
#15: 2012-04-06 13:23:01 ЛС | профиль | цитата
Что 3.14здец, то 3.14здец.
А я другие вопросы задам (вернее задайте их себе):
Перечислите пожалуйста по пунктам (для себя, а можете выложить и сюда)
1. Достоинства применения xml
2. Недостатки применения xml
3. Достоинства применения txt
4. Недостатки применения txt
5. В чем преимущество xml перед txt (для пакетов HiAsm)
6. Что даст замена txt на xml (про 10-кратное увеличение ini-файлов писать не надо).
карма: 24
Немного терпения! Дежурный экстрасенс скоро свяжется с Вами!
0
Сообщение
...
Прикрепленные файлы
(файлы не залиты)