Здравствуйте, _hum_, Вы писали:
CS>>Не устраивает двумя моментами:
CS>>1. Возможность возникновения event/signal loop. Невозможность доказать статически отсутсвие таких циклов.
__>так а разве этим не грешат любые варианты организации двунаправленной связи между объектами?
А зачем там двунаправленный механизм?
CS>>2. Инфраструктура signal/slot занимает ресурсы. Как минимум память.
CS>>При условии наличия альтернативных механизмов свободных от 1 и 2 использование сигнал-слот представляется спорным.
__> а можно узнать об альтернативных механизмах, которые бы преодолевали эти два пункта, при том же самом функционале?
всякого рода event buses. Или как вариация оных bubbling events в browsers.
Используют тот факт что объекты уже находятся в дереве. Т.е. связь child parent уже есть.
Если child генерирует событие то это событие bubble up (здесь — всплывает) по цепочке от child ко всем его parent.
Таким образом если какому-то контейнеру нужно обработать событие от child он (контейнер) может это сделать без всякой подписки и механизма с ним ассоциированного. Плюс каждый parent может что-то добавить к событию или "потребить" (consume) его.
В Web events есть еще так называемая sinking или capturing фаза —
http://catcode.com/domcontent/events/capture.html
Когда parents в иерархии получают события до детей. Т.е. в этой фазе parent может не пустить какое-то событие в child.
Т.е. механизм
не требует вообще никакой доп. памяти и структур (кроме тех что уде наверняка есть типа parent child)
гибкий и мощный — позволяет разные event handling & delivering policy использовать.
принципиально свободен от проблемы циклов (loops).
