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

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

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

А вопросы эффективности отрабатывать на 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) Как эту схему преобразовать в код: чтобы душа развернулась, а потом обратно свернулась

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

у меня тоже вопрос в том, что хочется иметь перед глазами хоть что-то, а то после прочтения постов этой темы начинаешь забывать с чего вообще читать начал. С точки зрения абсолютного практика считаю необходимым остановится на реализации изложенный выше концепции в её полном объеме и посмотреть, насколько она:
1) удачна
1.1) легка в освоение пользователем
1.2) понимаема им
1.3) удобна в конце концов
2) расширяема
2.1) наследие
2.2) инкапсуляция и т.д. и т.п.

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

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

А вот если ты опять про наследование и полиморфизм, то тут пока ничего не поделаешь, кроме как запихнуть все варианты внутрь одного мультика и хранить в нём собственно тип в виде числа.

Не опять, снова


А я предлагаю по-участвовать всем в преодолении этого "пока"
Потому-что из ничего и бывает ничего

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

я про много чего умолчал для того, чтобы не перегружать идею излишними деталями. Порядок следования полей в данном случае можно например определять и так:


------------ Дoбавленo:


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



можно б было много чего построить на этом элементе...

Такое предложение.
Для описания интерфейса делаем компонент без точек со свойствами имя, иконка и списки точек, как в EditMulti.
В MultiElementEx добавляем возможность объявлять Var-точки со специальными именами, соответствующими имени интерфейса (возможные варианты можно разместить там-же где и ##-точки, но с другим префиксом), при этом внутри мультика появляется новый неудаляемый элемент, который выглядит как и соответствующий интерфейс, но точки должны быть зеркально отражены (Work <=> Event, Var <=> Data).
Для использования интерфейса делаем компонент, у которого есть свойство "имя интерфейса", выбираемое из списка имеющихся. При этом после выбора появляются точки интерфейса, плюс одна Data точка для связи с источником интерфейса, имя которой совпадает с именем интерфейса (либо точка пятого типа, на углу компонента с небольшим отступом ). А можно и задействовать ссылку на компонент-описатель интерфейса.

Как видно, поддержка в среде должна быть достаточно нехилая.

не понял зачем прописывать имя интерфейса в св-ве и еще его же связывать с источником.

Интерфейс, полученный у мультика, может храниться в обычной переменной, в этом случае по схеме не определишь, какой интерфейс использовать надо.
Кстати, потребуется и массив полученных где-либо интерфейсов, иначе ни о каком полиморфизме говорить не приходится.
Я всегда удивлялся, почему есть массив целых, строк, но нет массива произвольных данных. Он мог бы в данном случае сгодиться.

думаю если не сильно увлекаться конструированием элементов типа GetIndexData, то определить тип и источник пришедших данных можно всегда. Во всяком случае, если речь идет о схеме в пределах одного проекта.


никто не заморачивался написанием таких элементов вот и нет

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

Это если рассчитывать на то, что на пути от источника до приёмника будут использоваться только определённые "известные среде" элементы, про которые она знает, какого типа данные выдаются, через какие точки могут прийти. Определять-то надо на этапе дизайна.

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

А как там поживает идея о том, что набор свойств и точек определялся бы в дизайн-тайме посредством скриптов?
То есть у нас есть поведение компонент в runtime, задаваемое исходником. Можно было бы добавить поведение компонент в design-time посредством скриптов (design time script - .dts). При отсутствии оного использовать какой-нибудь default.dts (или там element.dts, dtelement.dts, ... в зависимости от имени класса элемента)
Но это я так - мечтаю
Иметь большую часть ХиАсм в скриптах или плагинах open source

------------ Дoбавленo:

А ещё! Поведение компонент в compile-time В смысле - codegen-time ... Хотя, .hws это вроде оно и есть...

dts это всенепременно будет. Скажем возможность многоязыковой поддержки в пакет можно было б как раз сделать на одних таких скриптах без именения кода среды. Идеально б было сделать это на RTCG - быстро, просто и в будущем переносимо.

А подробности можно
Расшифровочку словосочетания "набор свойств и точек определялся бы в дизайн-тайме" - в основном...

Galkov, это-ж вроде бы твоя идея и была.

А насчёт интерфейсов, наверно можно обойтись и меньшими изменениями.
1. Как предлагает Galkov делаем ##handle не числом, а объектным типом (data_object). При этом мы избавимся от цикла в ##hselect, повысив его быстродействие. Появляется возможность использовать "чужие" ##handle, чего я когда-то очень хотел
2. Чтобы решить проблему возникновения событий "там, где надо", делаем у TEditMulti поле FCaller, которое будет устанавливать на себя (и сохранять перед этим в локальной переменной) MultiElement перед вызовом точки у EditMulti. Соответственно EditMulti должен пользоваться этим полем вместо родителя при генерации событий наружу.
3. Чтобы использовать ##handle как интерфейс, нужно сделать у мультика верхнюю точку (назовём условно ##hobject). При этом, если эта точка имеет связь, каждое обращение к неслужебной точке будет вызывать запрос через эту точку "интерфейса" и выбор данного мультика.

При этом никаких изменений в среде не нужно.
Разве что, можно всё-таки разрешить вставлять ссылку на мультик внутрь себя, но только в динамическом режиме и автоматически выставлять верхнюю точку ##hobject.

как-то так наверно:

тип data_element можно бы было на 100% реализовать в одних скриптах, не залезая в среду