Ага, пользовательдолжен сидеть и думать, куда там чего определить. ИМХО. Все должно делаться автоматически. Не надо никаких универсальных данных, и если за этим будет следить среда, не кодогенератор, а тем более пользователь, то ошибки сведутся к минимуму. Надо копать к полной автоматизации процесса конструирования. И особенно, если мы будем использовать глобальные объектные модули, которые имеют строго типизированный набор данных.
iarspider, для простых типов пойдет, а для структур можно будет сделать отдельным элементом, где можно будет описать эту структуру. Это в первом приближении, над этим можно подумать позднее.

Извиняюсь, конечно, имеется ввиду разработчик пакета.

nesco, ну не сможет среда узнать обо всех типах для всех языков, если её этому не научить. А как? Доделывать среду под каждый новый конечный язык? Про объектные модули не понял - имеешь в виду их как звено, предшествующее процессу кодогенерации? У меня сложилось впечатление, что ты мыслишь о среде, сделанной под один конечный язык/компилятор.

В FTCG ощутил то ли проблему, то ли неудобство в задании типов с помощью чисел: получил данные с точки, определил их тип (число), а как в конечном коде объявить переменную для хранения данных этого типа? Приходится делать сопоставление типа и его названия в конечном языке с помощью монструозных if() и switch()

Да очень просто -- в описаниях точки

Нет, не под один, а под многие. Вопрос -- как мы используем dll, в одном компиляторе, если она сделана в совершенно другом И именно в dll данные строго типизированы. Это к примеру

Мне кажется, не нужно работать с чужой dll на уровне схемы. Компонент, использующий эту dll, должен скрывать от пользователя тонкости реализации, оставляя его в рамках ограниченного количества типов, принятых для пакета (как есть сейчас). Конечно, никто не запрещает делать примитивные компоненты для конструирования из них произвольных структур данных. Это возможно с текущими кодогенераторами FTCG/RTCG.

С этим согласен: точке указывать тип данных (текстом, а не числовым кодом), а в свойствах пакета сопоставить типу цвет точки.

отслеживать должна, а с "предлагать" не согласен. Конвертор должен "ставиться" автоматом.

Что-то типа того
------------ Дoбавленo в 19.29:

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

На данный момент RTCG даёт возможность реализовать всё что угодно, и даже возможность пользователям создавать свои структуры в неких специальных контейнерах-конструкторах, другое дело среда значительно устарела для RTCG...

Используя скриптовой язык RTCG или как-то иначе Разговор идет о том, что в идеале не должно быть никаких скриптовых языков в принципе, все должно делаться только графическими блоками, и сама среда впридачу

nesco, конечно - блоками

Т.е. разработчик тоже должен строить пакет из кубиков?
Или я не понял)

Ну вот мы и пришли к главному "филосовскому" вопросу: "ЧТО БЫЛО РАНЕЕ КУРИЦА ИЛИ ЯЙЦО?"

------------ Дoбавленo в 11.04:
Или, nesco, исключает разработчиков пакетов из понятия пользователь. Надо договариваться о терминах.

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

Что это за привычка выдергивать контекст, не ознакомившись со всеми постами топика. Вот тебе ответный вопрос, заданный не мной.


Ответ не мой.


Мне ничего пока не надо вообще, надеюсь, вполне ясно выразился Я увидел интересную идею и попытался в нее вникнуть с одновременным доведением своих мыслей до народа. Увы, народ не понял, и пошел пиннать доводящего. ИМХО. Все, я ухожу в тину. Есть генератор идеи (Galkov), пусть он теперь до вас доводит свои мысли.

nesco, не обижайся, никто ж никого пока ни в чем не упрекал. Ну, если и кто-то что-то не так понял - так мы ведь тут и общаемся для доведения своих мыслей до других. Просто увлекательная беседа, помогающая самому себе придти к неким (полезным) выводам.

Свою идею Galkov изложил доходчиво. Взять некий базисный язык. Пусть для примера это будет Basic, описанный здесь. Так вот, если удастся релиазовать в графическом представлении некоторое множество примитивов, при помощи которых станет возможным не только генерить некий код, использующий следующие ключевые слова:
но и строить всевозможные синтаксические конструкции, понимаемые интерпретатором, компилятор или чем-то ещё, то можно говорить о совокупности графических примитивов, как о неком графическом языке, достаточном для решения, определенных перед этим языком задач.