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