Вверх ↑
Ответов: 9906
Рейтинг: 351
#1: 2007-05-31 14:47:13 ЛС | профиль | цитата
Ой, чего-то не там мы постимся
А средств отделения/переноса постов и нет

Dilma писал(а):
проблема в том, что не понятно на каком уровне и как отлавливать такие вещи. Проще всего очевидно в самом компоненте: если его точка вызвана повторно, то труба.

Да, вообще-то, понятно на каком

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

Частично это так сегодня и есть: мы получаем имя некой переменной (а это код!) в результате.
Но гораздо правильней (в этой парадигме) было бы получить код целиком (а не в codeb) и уже самостоятельно решать (в скрипте метода, конечно же) в какое место его засунуть

К примеру, вызвали скрипт, И ПОЛУЧИЛИ В РЕЗУЛЬТАТЕ, кроме еще никуда не засунутого кода - и синтетический атрибут типа <засунь свои данные себе в зад>
Ну вот, а мы тут считали, считали (предположим, была сложная арифметика).
Вот все и учли: свой код аннулировали, вернули такой же атрибут вышестоящему нетерминалу, и вернули ему только-что полученный код, как результат своей работы.
А было бы скажем <AsString> - сохранили бы свое сложное вычисление и вклеили конвертор типа

Аналогично и с рекурсиями... Только это теперь уже наследуемый атрибут
Сначала с верхнего уровня передается <Можно>
Предположим элемент For при парсинге onEvent говорит <Низя>, а при onStop - вышестоящее указание.

Еще один момент.
Мы начинаем парсинг с одной точки...
Смысл в том, что при совершении ф-ного вызова мы должны добавлять в некий список "необработанных точек входа" эту ф-ю.
Закончим парсинг этой ветки - перейдем к этой...
карма: 9

0