[Pharo-project] Why announcer subscriptions is dectionary?
Hello, I found that subscribers handle announcements in order differ then order in which they subscribe. Reason - announcer subscriptions is dictionary. Maybe dependency of announcement handling order is bad code design. But it can be usefull. Example. I need announcerA delegates announcements from another announcerB. And I need announcerA handles some specific announcement for own task. I try this code: announcerB on: SpecificEvent send: #specificHandler: to: announcerA. announcerB on: Announcement send: #announce: to: announcerA I want announcerA handles SpecificEvent (by #specificHandler) before other subscribers to announcerA .With current announcements implementation this code not work. What you think about this? I see announcer implementation. And I dont found some reason for dictionary subscriptions. Maybe we can fix it.
It is a dictionary for speed reasons. A user might trigger trigger thousands of events per seconds and iterating through large flat lists can be very slow if there are many handlers. Generally when using event handling (or the observer pattern in general) one should not rely on order. Thats would be very fragile, because anybody might register its own event handlers at any time. In your example I suggest that you only register the more generic handler and dispatch to the more specific handler in your own code. Lukas 2010/6/17 Denis Kudriashov <dionisiydk@gmail.com>:
Hello,
I found that subscribers handle announcements in order differ then order in which they subscribe. Reason - announcer subscriptions is dictionary. Maybe dependency of announcement handling order is bad code design. But it can be usefull.
Example. I need announcerA delegates announcements from another announcerB. And I need announcerA handles some specific announcement for own task. I try this code:
announcerB on: SpecificEvent send: #specificHandler: to: announcerA. announcerB on: Announcement send: #announce: to: announcerA
I want announcerA handles SpecificEvent (by #specificHandler) before other subscribers to announcerA .With current announcements implementation this code not work.
What you think about this?
I see announcer implementation. And I dont found some reason for dictionary subscriptions. Maybe we can fix it.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
It is a dictionary for speed reasons. A user might trigger trigger thousands of events per seconds and iterating through large flat lists can be very slow if there are many handlers.
Where is speedup improvements? In code that I found in Pharo 1.1 there is simple iteration by all dictionary items. And I think there is no places for speed improvements because subscribers can subscribers for announcement hierarchy (not concrete class). Announcer>>announce: anAnnouncement | announcement | announcement := anAnnouncement asAnnouncement. subscriptions ifNil: [ ^ announcement ]. subscriptions keysAndValuesDo: [ :class :actions | (class handles: announcement) ifTrue: [ actions valueWithArguments: (Array with: announcement) ] ]. ^ announcement
Where is speedup improvements? In code that I found in Pharo 1.1 there is simple iteration by all dictionary items. And I think there is no places for speed improvements because subscribers can subscribers for announcement hierarchy (not concrete class).
Announcer>>announce: anAnnouncement    | announcement |    announcement := anAnnouncement asAnnouncement.    subscriptions ifNil: [ ^ announcement ].    subscriptions keysAndValuesDo: [ :class :actions |       (class handles: announcement)          ifTrue: [ actions valueWithArguments: (Array with: announcement) ] ].    ^ announcement
The #handles: method is not called on each registered handler, but only once per "class". Lukas -- Lukas Renggli www.lukas-renggli.ch
participants (2)
-
Denis Kudriashov -
Lukas Renggli