Но все-таки не все ладно в нашем королевстве, мне продолжает казаться...
Специально повторюсь: это все я не специально придумываю, мысли сами в голову лезут
Вроде бы вышеупомянутого перечня зависимости точек для элемента (не важно, каким образом добытого: парсингом, или из конфига) -
не достаточно.
В смысле: понятно, что любая информация - это лучше, чем ее отсутствие. Но лучше иметь максимально полную информацию.
Не задаваясь вопросом, нужна ли она именно сегодня. Принимая за аксиому, что все равно понадобится (хотя, возможно - и не сразу). Главное - определить объем этой информации, и сформировать механизмы доступа к ней.
Мне (сегодня) такая информация об элементе представляется примерно в таком виде. Для каждого метода элемента указываем не только вызываемые события, но и их последовательность
Более того, можем указать альтернативные варианты последовательностей
Смысл необязательных условий на "варианте" имеется только тогда, когда они могут быть вычислены в Design-Time
Естественно.
Но когда это происходит - это оптимизация типа Dead End Elimination.
Ну, к примеру, если никогда не происходящий onFalse меняет какие-то данные, то сия "подключенность" уже никак не добавит точку doCompare в список "достижимых" при определении обсуждаемого ранее качества Volatile
А разбиение на "вариантность", позволит установить в таком примере
"недостижимость" точки Memory.doValue при вычислении Op1 во втором If_Else
И в нем, кстати, условие и посчитается в Design-Time
Если, конечно, мы умеем устанавливать вышеупомянутую "недостижимость"
Это скажем информация о классе элемента. И она должна быть превращена CG в информацию для КОНКРЕТНОГО элемента.
Парсингом, или еще как-то, но в этих "строках" должна появиться информация об использовании входных данных, и именно в нужном месте. Ну например
- здесь имеется в виду, что: а) условие не разрешимо в design-time б) первый операнд идет с верхней точки в) второй из потока (первые данные из MT-списка) г) на выход попадают данные потока.
Если факт одного использования установлен (второй операнд), и точно известно, что он ПОСЛЕ события Op1, и ДО событий onTrue или onFalse, то факт использования в выходном событии - только на последующих проходах (кстати, кроме самого факта использования, лучше бы знать и к какому типу данные приводились при использовании).
А ведь это влияет на принятие решения про "буферизацию"
Если Op1 не "портит" входной код, то буферизацию все равно надо провести, при двойном (или больше) использовании входного кода...
Т.е., при этой реализации, принятие решения зависит от фактора "использования" выходным потоком
Тут ситуация такая: точно сказать, как надо получать это "использование" даже "внутри" конкретного элемента (да еще на каждую ветку реализации) - пока не могу
Пока могу совершенно точно сказать - это очень надо
Подозреваю лишь, что факты "использования" почти синхронны "авто приведению типа"...
И вроде бы, в обсуждаемый "вариантный" способ вписываются почти все наши сегодняшние знания о функционировании элемента. Хоть хелп такой канонизируй - именно таких знаний не хватает сегодня пользователю для понимания "чего куды попадет" на схеме
А если еще подумать, когда нам нужна "буферизация", то начинает доходить, что ровно тот же разговор применим и к верхним событиям
Т.е., код, полученный сверху, может прямо в коде элемента использоваться неоднократно
Ну, скажем в неком гипотетическом скрипте написано:
Где и кто должен писать код буферизации?
Мне представляется, что именно CG при обработке точки
Str1 по информации MultiUsed от предыдущих проходов.
Так же как и для обработки
event - мне здесь тоже так кажется.
И все-таки информации, заложенной в SubType - явно не хватает. Ну хорошо, пусть мы установили факт MultiUsed и провели "буферизацию". Все равно в данных у нас код, но того, что дальше заниматься буферизацией уже не умно - у нас ведь никакой...
Установили мы, что для HUB есть факт MultiUsed
Отлично, проводим "буферизацию"
Но для If_else тоже есть факт MultiUsed
А ведь причин для "буферизации" - уже никаких
Вопрос ведь...