nesco, а заставить codegen думать над типом данных ?
------------ Дoбавленo в 01.06:
При чем здесь оболочка ?

Вот мы и пытаемся определить, что должна делать среда, те выработать концепт. Может для этого достаточно сделать оболочку для RTCG, может необходимо разработать что-то новое, может еще чего-то надо. Вы все почему-то выступаете в роли кодеров, а не в роли ведущих разработчиков. Скажу прямо -- ни от кого из вас пока не видно никаких приемлемых идей по концепту, а только срач по поводу, чей ... толще и длиннее.
------------ Дoбавленo в 01.22:

И как это осуществить Мне кажется, что это может делать только среда при подключении линка к элементу, тк она может прочитать его тип из описателя точки (это может быть загруженный ini-файл или данные из базы, определиться еще надо с этим). Те, среда должна совместить типы источника и приемника, я предлагал вставлять конвертор, а не делать автоматическое преобразование в коде на все случаи жизни, тогда мы бы видели, что у нас во что преобразуется, и могли добавлять что-то свое под необходимые нужды на уровне пользователя, а не разработчика, как сейчас. Те новые конверторы и описатели мы могли бы делать сами и вставлять их как элементы среды.
Кроме того, я предлагал создание глобальных элементов, что бы разные схемы можно было открыть в любом пакете. Туда еще можно будет воткнуть индикатор наличия конкретной доступности глобального элемента для определенного пакета. Но глобальные элементы должны быть универсальны для любого пакета. Предположим, создан глобальный контейнер таблицы, имеющий описание точек входа и выхода (некий API для элемента), тк вот этот контейнер можно будет наполнять более мелкими элементами для выполнения необходимых функций внутри и стыковкой с интерфейсом. Но должно соблюдаться одно правило -- каждый элемент это глобальный контейнер, тогда можно будет имет неограниченную вложенность. У нас прототип такого уже есть -- шаблоны

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

Да при том, что если начали искать резинку от трусов, то ищем, и не более того. У меня один вопрос??? Кто-то взялся за проект? или как всегда?.Мы здесь мы с вами! Еще раз повторюсь, что весь разговор к хорошему не приведет. Если есть рукоделы вперед а не тря-ляя-ля-ля! Двери открыты, чем смогу помогу, я даже готов посмотреть как С++ яп работает. С nesco я согласен по этому ответу:
------------ Дoбавленo в 01.53:

Да причем здесь это? вы видели что-бы было утверждение по языкам?

Если же стандартизировать разработку пакетов по примеру C++ International Standard, то тогда придётся заранее создавать оболочки (шаблоны) элементов со стандартизированным описанием, задуманной логикой и точками, и далее в каждом пакете пытаться реализовать логику данного стандартизированного элемента возможностями ЯП.
Если я правильно понял идею про глобальные элементы?)

Вы сейчас про что?
------------ Дoбавленo в 02.01:
Причем здесь среда и язык? Я вам сейчас могу накидать Среду без кода гена, что вы с ней можете сделать?

Kazbek17, извините, но я Вас не понимаю.
Вы имеете представление о построении пакетов с помощью FTCGRTCG, как это всё "крутится" и взаимодействует со средой?

[flood]Проехали: Я Свое мнение сказал, Зачем? поясните на ушко! [/flood]

Ну, понеслось -- опять за рыбу деньги
Что все пытаются прикопаться к тому, что есть, а не к тому, что может быть
Мы пытаемся для начала понять, что нам надо, а не как это реализовать. Как реализвать, и можно ли вообще, какие будут трудности, это все должно быть потом, после выработки концепта
------------ Дoбавленo в 02.25:
Давайте для начала представим, что у нас нет никакого HiAsm-a, ну нет, и все тут, начинаем разработку с нуля. Может так легче будет

Давай пока среду оставим в покое. Меня пока среда полностью устраивает. То, что у неё объявлено в меню, она выполняет.
Мы можем результат codegen-а перед компиляцией прогнать через какой-то "оптимизатор" (пока в тумане), который выбросит лишние строки, согласует типы данных и т.д. ?
Что, в принципе и делает RTCG (и то не до конца - только удаляет лишние строки)

Типы надо прописывать вручную на этапе разработки. Нет возможности "на лету" создать свой тип из доступных элементов. Полумеры все это. ИМХО

Согласен.
Если начинать проект сверху, то (моё мнение)
Что нужно для начала:
1. Редактор формы.
2. Редактор схем
3. Универсальный компонент типа мультиэлемента у которого можно:
а) присвоить ему имя
б) создавать точки "снаружи" (как на Hab-е)
в) создавать точки "изнутри" (как в мультиках)
г) давать осмысленные имена этим точкам и ТИП ДАННЫХ.

а для его наполнения у нас пока всё есть.

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

Нет у нас ничего. То, что есть оставим в покое. Я так думаю, что необходим еще один элемент -- IC, в котором можно не выходя из среды писать код на целевом языке пакета и который может в дальнейшем превращаться в элемент модуля для определенного пакета, типа элемента конечного построения.
И я бы не стал делать верхних точек у глобального элемента построения, только вход и выход, причем, каждый выход должен быть результатом рабты определенного входа, а вход есть некоторый метод внутри элемента. Получается организация элемента по типу API dll. Для передачи переменных должен служить специальный элемент переменных, в котором переменные передаются сверху, но не в потоке, на входе такого элемента ничего нет, самому элементу присваивается имя вызываемого метода, на выходе получаенм некоторый псевдоскрипт вызова метода с переменными из целевого элемента.
Пока получается три минимальных глобальных компонента -- элемент конечного построения, элемент переменных, контейнер
Все это только один из вариантов. Могут быть и другие.

Это как раз то о чем говорил Galkov

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