Редактировалось 1 раз(а), последний 2017-03-06 02:34:39

Ой, давно не выкидывало Наверное, глупость сморозил

Леонид, не обязательно в машинных кодах. Самый низкий уровень - это (декларация и) вызов произвольных функций из библиотек, передача и получение произвольных структур (классов) с доступом к полям этих структур (классов). Этот уровень мало чем будет отличаться от обычного программирования - по сути это будет аналогом нынешнего IC, но только код будет не текстом, а "кубиками".

nesco, ты хочешь сказать, что если будет концепция и генеральная линия, то найдётся тот кто займётся разработкой? Нет, не найдётся, за скромную плату тоже! Скорее будет разработчиком тот, кто эту концепцию и генеральную линию придумает/сделает! Займётся разработкой только тот, кто либо горит желанием осуществить идею, причём не затухающее горящее желание, либо тот кто найдёт в этом хорошую выгоду! Второй вариант более вероятен! Но есть и третий вариант, который будет осуществлён с вероятностью 50/50, заняться этим всем вместе, кто имеет к такому проекту интерес, но это будет не просто! ))

iarspider, (с точки) нет, с плоскости! зрения профана "это (декларация и) вызов произвольных функций из библиотек" привязка к определённому языку а цель: " компилятор не потребуется"

hitman249, вопрос на засыпку -- Java может создавать объектные модули, которые можно будет прилинковать к своему приложению
------------ Дoбавленo в 14.58:

Он не потребуется, как таковой, в случае если использовать объектные модули, но тогда нужен линковщик этих модулей, и модули должны быть написаны в одном стандарте. К примеру, у нас такое есть в SQLite, там могут пристегиваться объектные модули, сделанные пес знает в чем

Леонид, это ты неправильно народ понял. Без компилятора ты всё равно не обойдёшься - разве что действительно в маш. кодах будешь программировать. С точки зрения среды есть кубик "вызов произвольной функции с произвольными аргументами". У этого кубика есть три свойства - "название" функции, количество аргументов (верхних точек) и (возможно) список типов. Всё, больше среда про этот кубик ничего не знает, остальное задача кодогенератора - как выполнить этот вызов, что делать с аргументами (преобразование типов, взятие адреса/разыменование, ...), как вернуть результат (если есть)
------------ Дoбавленo в 15.04:
nesco, вообще говоря да - class-файлы. Но они работают только внутри java-машины, задействовать их из C++ или C# будет не так просто (пусть коллега поправит меня, если я не прав).

А кто тебе сказал, что пристегиваемый блок не может содержать внутри себя некий интерпретатор, почему именно компилятор, важно, чтобы блок принял входные данные, переменные и выдал на выход результат действия.
Конечным результатом концепции должна быть возможность создавать саму среду из самих же компонентов разных пакетов, насколько я понял Galkov-a. Но я бы добавил одно условие -- все примитивы, всех пакетов должны быть идентичны по параметрам. Сейчас же у нас -- кто во что горазд

nesco, "компилятор" в общем смысле .

Черта с два. Если оставить понятие TData, то и на С++ будет ползать.

Не должно быть TData, не должно быть никаких универсальных типов, только строгая типизация линков, я уже писал, что среда должна отслеживать тип линка и предлагать вставить в разрыв конвертор. Но и должна быть возможность изменить тип точки, предположим, для такого варианта -- у нас одна переменная типа String используется пятью точками типа Integer и одной типа String, среда расставила конверторов для типа Integer, можно, в таком случае, изменить тип этой точки на Integer, тогда среда должна автоматически убрать конверторы с типа Integer и поставить конвертор на тип String. Таким образом, получится оптимизация схемы. Как тип такой точки будет меняться в модуле, тут подумать надо. Для глобального проектного модуля типы значения не должны иметь, для готового мы такое сделать не сможем, это все должно отслеживаться средой

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

А вот насчет типизации линков - а есть ли смысл? Сейчас в пакете Delphi мы не задумываемся о типе данных. Благодаря этому мы можем сосредоточиться на задаче, а не на соблюдении правил соединения, нарушение которых приведет к ошибке компиляции.
Конечно, при неправильном соединении точек программа не будет работать как ожидалось. Но это лишь значит, что пользователь не до конца разобрался в применении конкретного компонента. В текущем пакете для обнаружения своей ошибки пользователь должен запустить программу и потратить некоторое время на её поиск.

В FTCG же можно ещё на этапе компиляции выдать предупреждение с полным описанием ошибки. Тут в среде можно добавить такую фичу, как мигание "ошибочных" компонентов и линков с отображением над ними Balloon hint с описанием ошибки.

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

nesco, согласен. Но коли уж об этом заговорили - конвертер должен быть мини-элементом (в визуальном смысле, a-la нынешние hub или даже HubEx), иначе половина схемы будет засрана (пардон за мой французский) всевозможными конверторами того-в-это. А ещё лучше - чтобы конвертер сливался с компонентом, оставляя лишь визуальный "хинт" (особая форма точки, скажем - не кружок, а ромб), чтобы (опять же) не тратить место на схеме на "служебные" компоненты.
------------ Дoбавленo в 16.35:
Netspirit, а теперь поищи по форуму, сколько раз народ "накалывался" с автоприведением типов в If_Else (сравнение числа и строки)?

iarspider, это из-за используемого кодогенератора, который на этапе компиляции никак не проверяет типы данных (см. выше).

В пакете RTCG также есть подобный механизм, определяемый пользователем в файле hiSys.hws и поддерживаемый вызовами из кодогенератора.