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

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

Так давайте об этом говорить

А вопросы эффективности отрабатывать на FTCG/RTCG. Мне представляется, что эта идеология совершенно не противоречит исходной (ну должно же быть чего-то исходное) модели "паровозиков".
Просто из этой идеологии надо убрать прилагательное "однопроходный", и все сварится.
Бога ради, я не собираюсь никого обращать в свою веру на этот предмет, но чтобы начать работать самому, мне необходимо серьезно изучить концепцию именно интерфейса.
Ну вот не умею я наоборот, и очень прошу извинить меня за это...
В общем, просьба в пианиста не стрелять

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

Про пакет Дельфи как средство испытаний:
Ну не определяет сегодня среда отношений наследования, и ##handle является целым числом...
И что...
Это от того, что, при имеющейся сегодня системе защиты (принадлежность только собственному листу) - этого достаточно.
Как только мы задумаемся о "чужих" хэндлах то сделаем его объектным типом.
Вон, Dilma давно уже предлагал сделать наш сегодняшний guid структурой из 2-х полей: сам guid, и указатель на guid-предка
Получится некая система RTTI. Но она будет работать.
И это ну аж никак не запрещает технологии FTCG/RTCG разрешить все эти вопросы в DesignTime

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



Ну мои предложения были таковы:

А мы просто протянем связь - ВИЗУАЛЬНО. Так как и со стримом, битмапом и прочей нечистью, которую в модели "паровозиков" мы именовали перевозкой в вагончике не объекта, а ПДУ на него. Мне даже кажется что это практически одно и то же...

У элемента должно быть свое св-во типа data_element - это ключ к распознаванию элементов на свой/чужой. Свои - это только наследники класса из этого св-ва. Чужие - могут себя не затруднять входными событиями.

А набор точек определяется НЕ ЛИНКОМ по первому пункту, а св-ом по второму. И моя принципиальная позиция заключается в том, что не только только точками класса (а у нас-то это просто мультик, и точки - вот они) св-ва, но и индивидуальным выбором. И мы обязаны просить Dilma об интерфейсе этого выбора. И не просто потому, что мне много точек отчего-то вдруг не нравится, а потому что результат выбора меняет функционирование.
Как бы, для понимания пользы этого выбора, я и пытался рассказать страшную историю про TStream в предыдущих постах.

Если не убедительно - ну извините, свои педагогические таланты я расцениваю крайне не высоко. Давайте задавать вопросы, что-ли...

tsdima писал(а):

В конце-концов, один объект может предоставлять несколько интерфейсов, как быть в этом случае?

А я полностью согласен
У нас неплохая аналогия с COM. И все слова, которые произносят апологеты COM, про то, что именно у них (не не в классическом ООП) и наследование более настоящее, и инкапсуляция более правильная - мы могли бы взять на вооружение.
Пустой мультик - это только интерфейс. Можно даже сказать что интерфейс, это элемент EditMulti
Несколько интерфейсов - точки добавляются.
Наполнение мультика - ну вот так он обеспечивает все возможные интерфейсы.
Получить какой-то конкретный интерфейс: ну скрыть все ненужное, оставить в default-е скрытые внешние св-ва...
Как быть в этом случае
А я тоже хочу задать вопрос и послушать здравые и красивые предложения
Может совместить с наследованием как-то.... Типа ничего не меняли (хотя, почему-бы и нет, но могли же и ничего не менять), только изменили профиль видимых точек и св-в......
Это - не более чем мысли вслух, пока...
------------ Дoбавленo:

Dilma писал(а):

Про пользовательские конструкторы данных я уже как раз думал. Особенно когда надо упаковать их в массив

А я даже видел "тренировки" коллеги tsdima на этот предмет
Кажется он делал схемку, которая настраивает цвета для синтаксической подЦветки для встроенного в HiAsm редактора
Точно не помню.

Dilma, вопрос то в том, что хочется делать по-сложнее: делать массив из TTreeNode (который определен в RTCGCodeTree.h) на HiAsm
Как бы я с этого и начинал: хиасмист - тоже человек
И он имеет право написать CodeGen на HiAsm
И предлагал разделить задачу на две части:
1) Как нарисовать такую схему
2) Как эту схему преобразовать в код: чтобы душа развернулась, а потом обратно свернулась

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