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.
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> 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