Сообщение Re[7]: "class const - метод" - можно ли организовать? от 24.09.2015 23:25
Изменено 24.09.2015 23:31 c-smile
Здравствуйте, _hum_, Вы писали:
CS>>Не устраивает двумя моментами:
CS>>1. Возможность возникновения event/signal loop. Невозможность доказать статически отсутсвие таких циклов.
__>так а разве этим не грешат любые варианты организации двунаправленной связи между объектами?
А зачем там двунаправленный механизм?
CS>>2. Инфраструктура signal/slot занимает ресурсы. Как минимум память.
CS>>При условии наличия альтернативных механизмов свободных от 1 и 2 использование сигнал-слот представляется спорным.
__> а можно узнать об альтернативных механизмах, которые бы преодолевали эти два пункта, при том же самом функционале?
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.
Т.е. механизм
CS>>Не устраивает двумя моментами:
CS>>1. Возможность возникновения event/signal loop. Невозможность доказать статически отсутсвие таких циклов.
__>так а разве этим не грешат любые варианты организации двунаправленной связи между объектами?
А зачем там двунаправленный механизм?
CS>>2. Инфраструктура signal/slot занимает ресурсы. Как минимум память.
CS>>При условии наличия альтернативных механизмов свободных от 1 и 2 использование сигнал-слот представляется спорным.
__> а можно узнать об альтернативных механизмах, которые бы преодолевали эти два пункта, при том же самом функционале?
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).
Re[7]: "class const - метод" - можно ли организовать?
Здравствуйте, _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.
Т.е. механизм
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).