Dilma писал(а):
опять не понятно: в чем и в каком месте ошибка? Что предлагается исправить/добавить/удалить? Пример?Ну уж не знаю и как
Давай попробуем по порядку...
Хоть там и отвлечения появятся от конкретной темы: "парсинг Единого_Свойства_События"
В большей степени я буду излагать свое понимание того, что у нас происходит, или должно происходить.
1) Начнем слева от интересующего нас события. А справа этого события стоит тот самый элемент, код которого зело велик для неоднократной инлайн реализации
2) В кодах левого элемента (да хоть бы и StrCat, к примеру) стоит event(onStrCat, s). Начинается работа CG.
Первое, что он делает, это устанавливает, что линк у нас идет к точке doMethod нашего конкретного элемента (код doMethod которого зело велик для неоднократной инлайн реализации)
3) Сейчас отвлечение. Может оказаться, что к этому же методу этого конкретного элемента есть иные обращения посредством HubEx. Или точка doMethod обладает атрибутом DPE и есть обращения точкам нашего же элемента, но с другими индексами.
Суть то одна и та же - неоднократное использование метода...
Так вот, ОЧЕНЬ хотелось бы обратить внимание, что хоть здесь и тоже необходим функциональный вызов, это совершенно отличается от упаковки метода элемента в метод объекта.
Грубо говоря - это два разных разговора.
Этот случай гораздо проще: если мы таки приняли решение о функциональном вызове (как мы должны принять это решение - пока не до конца понятно), то теперь в задачу именно CG входит формирование этого функционального вызова (это языково-зависимый фокус, поэтому видимо через вызов скрипта из какой-то системной библиотеки, или расширять функциональность direct.inc надо) в текущий блок с необходимыми фактическими параметрами, и сформировать в другом блоке (видимо в BLK_MTD_BODY) определение ф-ии с необходимыми формальными параметрами. В качестве тела ф-ии влепить исполнение скрипта для doMethod, фактические параметры которого и есть формальные параметры определяемой ф-ии.
4) Вот и все, в этом простом случае, и принципиальных проблем тут не очень видно.
Кроме одной: все это должен делать CG, и не очень ясен критерий принятия решения FUNCTION.
Это как-то должно зависеть от размера кода ВСЕЙ алгоритмической ветки, а не от типа первого же элемента в этой ветке. Он вообще может быть типа AlwaysInline.
А с другой стороны, всегда (по любому Ex-у) принимать решение Function - тоже глупо. Ведь то же самое относится и к вертикальным связям, что встречается в схемах гораздо чаще.
Ясно, что глупо превращать в функциональный вызов код, который возвращает по вертикали что-то типа Btn_15.Caption, хоть и используется эта точка раз 20...
5) А теперь закончим отвлечение - нет у нас повторных вызовов одной и той же точки.
Тогда CG просто запускает в работу ф-ию doMethod нашего элемента, имея в контексте именно этот конкретный экземпляр. Этот контекст и позволяет нам (CG) далее парсить, к примеру св-ва X, Y и Z.
И все нормально, пока мы не обратили внимание на то, что: а) таких элементов на схеме несколько б) код метода зело велик для неоднократной инлайн реализации
И вот тут, если мы захотим упаковать этот метод в функциональный вызов, начинается тот самый другой разговор. Как отмечал выше, он серьезно отличается от разговора по пп..3,4
Грубо говоря - это два разных разговора, хотя похожие слова и встречаются.
6) У меня нет никаких возражений против формирования функционального вызова с дополнительными аргументами, при фактических параметрах типа "св-во" или "данные потока"
В случае если в нашей схеме не встречаются реализации нашего элемента, когда данные берутся с верхних точек - замены наших макросов X, Y и Z на формальные параметры, или поля объекта, могут оказаться самыми оптимальными.
Здесь конечно есть незакрытый вопрос: каким это макаром формировать тело метода. При запуске ф-ии скрипта мы имеем конкретный контекст - выбранный элемент. В нашем случае не должно быть выбранного элемента, код должен быть одинаковый для всех экземпляров данного класса.
7) У меня есть категорические возражения против подставления в фактические параметры вышеупомянутых функциональных вызовов - результатов работы верхних точек.
Скажем для
println('doMethod(', data, X, Y, Z, ');')[/code]
Какой код мы получим?
Что есть [b]data[/b] для CG тайной не является, и код для него уже сформирован (если левый StrCat, то это может быть код для переменной результата 's15'). Далее формируется код вызова верхней точки [b]X[/b]. Это может быть не просто типа 'btn15.width', но и нечто более серьезное с добавками строк кода в текущий кодовый блок (ДО вызова [b]doMethod[/b]).
Но даже вызов btn15.width до функционального вызова doMethod - уже неправильно категорически
Аналогично и с [b]Y[/b] и [b]Z[/b]
Почему неправильно ???
Вот тут я снова и не понимаю что сказать - настолько для меня это очевидно :shock:
Да потому что не дело CG вызывать методы по собственной инициативе. Это дело - вызывать их по инициативе скрипта.
И никак иначе: неведомо для CG, сочтет ли необходимым код, формируемый скриптом вызывать их вообще, если сочтет, то в каком порядке, и сколько раз каждый.
8) Собственно, иного варианта для такого случая, как формировать отдельные ф-ии, и подставлять в фактические параметры адреса этих ф-й ([b]но никак не их вызовы[/b]) - я и не вижу...
Поиск
Друзья
Администрация