Придумал еще один способ, но для него мне понадобилось узнать что подключено к HubEx. Не получается
Мои попытки:
В "func init" элемента Hub дописываю две строчки
Запускаю твою схему и получаю чудеса - одинаковый ответ
Если подключить кнопку, то все работает правильно

Да, но здесь другой случай: "финализирующий" метод выполняется после завершения обхода (рекурсивного) всего дерева элементов. Что получится, если к этому моменту где-то будет не хватать кусков кода, которые должны были получиться на «оптимизируемых» хабах?
Можно, конечно, поэксперементировать... только не понятно в чём будет выигрыш в конечном итоге...

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

При вызове doEvent хаб может впечатывать в код вызовы методов, а тела этих методов генерировать и печатать при "финализации" на основе логики оптимизации.

Но это так, мысли вслух. Я не владею тонкостями этого пакета и предлагаемых оптимизаций.

В простейшем случае (единственный вызов хаба), хаб не порождает «дополнительного» кода, кроме последовательности кодов событий onEvent(data). Дополнительный код появляется только в случае повторного вызова хаба. Использование перегрузки методов вместо конвертации входных данных к заранее, кстати не известному типу, тоже логически оправдано.

Да, понятно. Вероятно, некоторые удобства в HiAsm нельзя реализовать без runtime-конверсии типов...
------------ Дoбавленo в 16.41:
[offtop]Ещё как-то возникала идея "а что, если бы хаб при обзвоне правых точек onEvent "спрашивал" присоединенные компоненты, какой-тип данных они предпочитают?". Ну, то-есть, любой метод левой точки и так вставляет ковертор данных к нужному ему типу. Вот хаб сам вставит конвертер только для этого события и сразу даст данные нужного ему типа. А для другого события он вставит другой конвертер.
Только:
1) Нужно, чтобы метод присоединенного компонента мог знать, какой аргумент в данной схеме он получит именно из потока, чтобы сообщить требуемый тип.
2) Придется каким-то образом для каждой левой и нижней точки предусмотреть возврат желаемого типа по требованию. Это добавляет работы автору компонента.
3) Могут быть компоненты, которые принимают несколько разных типов в один метод. Тогда компонент выдает список поддерживаемых типов в порядке приоритета, а хаб выбирает сначала тот, который не требует конвертации, а если таковой отсутствует, конвертирует к первому в списке типу.
[/offtop]