Так я думал есть готовая функция котороя выводит полный путь всех ключей.
Типа вывел все и компонентом Hilight нашёл и переименовал.

[size=-2]------ Добавлено в 14:46

А почему Delphi если он на С++.

Взято из слов г-на Galkov, а.

А ничего красивого.
Что мы имеем после элемента Function: содержимое некого мультика, у которого (по неизвестным причинам) только одна левая входная точка, нужное количество верхних точек, и отсутствуют нижние и правые.

Но соглашусь, для факториала - хватит.

Позволительно ли будет иметь пользователю такую точку зрения
1) Я не знаю что такое функция
2) Но я знаю, что решение любой задачи - это вызов метода (или нескольких методов) некого объекта.
3) Следовательно, мои действия должны быть таковы: создал объект, выполнил необходимые методы, уничтожил его.
4) И другого не существует в природе. То что существует - лишь частное проявление этого же принципа.

И еще отмечу, что в сегодняшнем проекте Дельфи рекурсивные задачи решались бы не менее красиво, ЕСЛИ БЫ среда передавала эту схему в CodeGen.
И безо всяких диспутов: нужны ли event-ы для рекурсивных задач, или не нужны...

как сказать С точки зрения результирующего кода лучше написать уже врятли возможно...


В пакете WEB одна левая, одна правая и неограниченное количество нижних и верхних. Очевидно, что ничего другого сделать невозможно без использования объектов, либо банального дублирования кода.


видимо имеет смысл вынести настройку в качестве параметра в кодогенератор.


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

Не понял
СЕГОДНЯ, как только CodeGen получит эту схему - так все сразу и будет работать.
Давно УЖЕ


Есть два разных разговора: интерфейс и реализация
В первом - ООП есть могучая сила.
Во втором - наоборот

И не в коем случае не утверждал я что и реализация должна быть в стиле ООП.
Как раз нооборот - придерживаюсь идеологии Кладова. Потому-что он прав. Результат ООП в реализации - это VCL, а отказ там же от ООП - это KOL.

Так проблема ведь не в том, что CodeGen получит что-то или не получит. Важно как раз то, будет ли это работать или нет. В Delphi Classic будет. В PocketPC не будет, и хорошо если еще среда не зависнет от такого. В FASM видимо тоже не будет. В WEB зависнет с переполнением стека - это уж точно. Вывод: безусловной такая вставка быть не может. Если элементы, вставленные как линки любой кодогенератор без особой обработки видит как просто копии с одинаковым содержимым, то от вставки контейнера в самого себя ему(кодогенератору) станет плохо.

Припоминаю, обсуждали - вроде не проблема сделать, что будет. И без выделения хедеров, даже...


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


У меня другой вывод: любой CodeGen обязан корректно (без громкого "кряк") обработать такую ситуацию.
Причем, ситуация, в отличие от "кольцевания" имеет совершенно однозначную интерпретацию.
На уровне среды безусловным запретом может статический линк наверх
И вообще, я сторонник разделить статический и динамический мультики: в них больше разницы, чем общего...
Возможны ошибки: не ограничит пользователь глубину рекурсии.
Ну, на то бесконечная глупость так и называется, что невозможно ее полностью исключить. Чего ж теперь, стреляться что ли...
У нас исключены так называемые лексические и синтаксические ошибки.
Семантику (пока это "кольцевание" только) может и обязан отловить CodeGen
Логические ошибки и ловить не стоит. И уж точно не стоит воспринимать возможность логической ошибки - как аргумент против возможностей среды


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

---

Добавить к предыдущему надо бы:

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

Да ничего он не обязан. И не обязан он потому, что это есть некоторое знание о возможностях целевого языка. Как я интересно должен ссылку на самого себя интерпретировать в проекте HTML Я представить даже себе не могу, что это может означать в рамках текстового языка разметки. А раз так, то ни о каком "обязан" и речи быть не может. Либо мы всетаки реализуем это "обязан" и сразу же говорим, что генерация по схеме может быть применена только для языков с возможностью процедурных вызовов, либо расширяем кругозор и предоставляем кодогенератору самому решать может он обработать такие схемы или нет.

[size=-2]------ Добавлено в 11:07
Кроме того, если забыть сейчас про вставку ссылки в самого себя, и представить, что в будующем могут появиться новые сущности среды, то утверждать, что каждый кодогенератор обязан всех их поддержать как только они появляются не правильно. Из соображений совместимости правильно будет запрашивать такую информацию у самого пакета.

Никак. О невозможности компиляции такой схемы должен сообщить CodeGen. Желательно с подсветкой "некорректной" связи.

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

И пусть в каких-то пакетах таких элементов не будет.
Зато в каких-то - БУДЕТ

Моими же средствами, на уровне CodeGen - это ведь недостижимо

я же не зря немного уточнил проблему



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


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

Еще парочка задач того же плана:
- ActionSkin - внутрь него впринципе нельзя вставлять ничего, кроме AS_Control, однако в среде этого определить никак нельзя.
- в большинстве случаев любое подключение верхней или нижней точки с типом array к точке с любым другим типом не имеет смысла. Однако опять таки же все, что мы можем сделать это проигнорировать такое подключение. Либо следуя совету:

мы должны в каждом элементе и в каждом его методе, использующем данную точу вставить проверку и выдавать предупреждение...

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

Это не совсем так. Мне, например, неизвестны способы обработки линков ИК без персонального учета этой ситуации в CodeGen.
Плюс к этому, я не понимаю, что такое линк на элемент.


Не вижу здесь проблемы в генерации кодов.
Но вижу недостатки.
К примеру, я хочу зарегистрировать в TabControl (через TControl.TC_InsertControl) неопределенное на этапе компиляции количество контроллов, например - Memo с Align=caClient
Скажем 1000 штук
Такой пример я на KOL-овский форум выкидывал, как тест на быстродействие переключения страниц и привязки.
Так я не знаю как у нас это сделать можно.
Точнее знаю - никак.
Но, если бы Memo помещался внутрь MultiElementEx - все работало бы.
Вопрос: имеем ли мы право требовать в такой задаче от пользователя создания дополнительных промежуточных панелей - 1000 штук кстати.
Не наблюдается логики как-то...

---

Вообще-то я не понимаю зачем все вопросы толкать в одну кучу
Разультат от этого может быть только один - отсутствие такового.
Что и наблюдается с самого создания линков

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

2) Есть задача создания элементов средствами HiAsm. И линки - наиболее близкий прототип для реализации этого. Почему при этом внешние св-ва мультика являются также залинкованными - непонятно мне. И тоже - с самого создания линков.

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

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

Galkov, ну видимо проблемы непонимания возникают из-за того, что я говорю об общем, а вы о частном. Привел же уже пример с проектом HTML... думал достаточно будет. Кроме того:

что называется сново здорово... Надоело уже

В общем оставляя попытки выяснить корни недопонимания предлагаю действовать иначе и конкретнее:
1) Есть факт: в среде можно сделать линк на элемент. Если этот элемент является контейнером и если этот линк вставлен внутрь контейнера, то интерфейс cgt предоставляет кодогенератору бесконечное дерево, обойти которое можно только заранее проверив является ли контейнер линком или нет.
2) Пути решения:
а) Galkov,tsdima: кодогенератор обязан делать указанную выше проверку и реагировать в зависимости от поддержки данной возможности или нет. Иное поведение считается ошибкой в реализации кодогенератора.
б) Dilma: кодогенератор предоставляет среде информацию о том, возможно ли вообще делать такие схемы в среде для данного пакета.
3) Выявленные недостатки подходов:
а) существует вероятность появления неверно работающего кодогенератора при его использование в более свежих версиях среды с новыми возможностями схеметехники
б) ???

Хотелось бы получить комментарий по пункту а) параграфа 3).
Хотелось бы получить описание недостатков метода б) параграфа 2).

Да ничего я не обхожу (хотя не исключаю такой возможности) сегодня.


Как бы не вижу проблемы при создании метода, который возвращает тождественно TRUE
Или условие Result := Mode=Dynamic



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

Это значит решение под пунктом б) является более приемлемым? Или как это понимать?


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