2013/7/21 St�phane Ducasse <stephane.ducasse@inria.fr>
Interesting how many people in this list think that "Announcer subclass: #TxEditor" provides special implementation of announcer named TxEditor?

Many�
this is composition using inheritance and inheritance should not be used like that.�

Announcer subclass: #GreedyAnnouncer

Announcer subclass: #RemoteAnnouncer

And if we prefer composition we should not implement such kind of hierarchy. We should implement GreadySubscriptionsRegistry,�RemoteSubscriptionsRegistry or AsynchSubscriptionsRegistry and reuse existed Announcer. All subscribing and delivering logic implemented by subscription registry. Announcer is just simple delegator with convenient api to create Subscription instances:

Announcer>>subscribe: anAnnouncementClass do: aValuable�
"Declare that when anAnnouncementClass is raised, aValuable is executed."
^ registry add: (
AnnouncementSubscription new�
announcer: self;
announcementClass: anAnnouncementClass;
valuable: aValuable)

Announcer>>announce: anAnnouncement

| announcement |
announcement := anAnnouncement asAnnouncement.
registry ifNotNil: [
registry deliver: announcement
].
^ announcement

All magic happens inside #add: and #deliver: methods of SubscriptionsRegistry.

Also announcements framework provides very nice feature: you can have�announcer as last argument of event handler selector (that's why��AnnouncementSubscription contains reference to announcer instance):

announcer on: MyEvent send: #handleAnnouncement:raisedBy: to: aSubscriber

Without subclassing YourEventsSource from Announcer you will not have such feature. Or you will need implement complex subscription method inside YourEventSource which will delegates special event handler to its announcer�