At Sun, 1 Nov 2009 20:22:48 +0200, Igor Stasenko wrote:
 If "can be logged" means to have #canBeLogged method that returns true, you could also say (given that you provide a default implementation of #canBeLogged at a/the root):
logblock := [:announcement | announcement canBeLogged ifTrue: [... ]]. announcer on: Announcement do: logblock.
i dont want to nitpick , but since you subscribing to the Announcement class, this means that you need to put an extension method #canBeLogged into it.
And we started this discussion from question: is Announcements framework is generic enough and won't require more coding. But extending it is already means 'more code' in base.
Well, I said "if". And if you really don't want to have an extension method in the base, you can say something like: (announcement instVarNames includes: 'canBeLogged') ifTrue: [...] or any other ways that don't require an extension method in the core. The point was that you don't have to have all 35 classes listed upfront.
Loading a package with new subclasses of Announcement is not a problem. Â And, a recipient ignoring an announcement that it doesn't handle is somewhat common, when I used my own implementation for my projects.
 If you implement an observer pattern to accommodate the new package loading requirement, what would be the strategy to implement it?
Not necessarily a new package. The problem is, that i don't want to modify multiple places in system if i reconsider whether something can be logged or not, as well as i want to be sure that my code will handle all and any potential changes in future without the need of any modifications in my code.
Ok... But announcement or not, you need a way to tell a notification "can be logged".
Another question , which Stephane noted already, is the overhead of broadcasting.
In Announcer>>announce: it iterating over all subscriptions to determine which one may want to receive an announcement or not.
subscriptions keysAndValuesDo: [ :class :actions | (class handles: announcement) ifTrue: [ actions valueWithArguments: (Array with: announcement) ] ].
but if we can't avoid iteration, then why ASKING but not TELLING to handle it:
subscriptions do: [ :subscriber | subscriber handle: announcement ].
(subscriptions collection can be just a Set in this case) and then , a particular subscriber could decide whether he interested in given announcement or not, based on own criteria (such as #canBeLogged etc).
And surely, we can provide a subscriber class, which can use the same logic, to determine if it interested in particular announcement, based on announcement class. This could make the whole thing more flexible.
But the client side code will be more messy. An object will have only one implementation of #handle:, and whenever you want to add a new thing to be handled by the object, it ends up with adding a new if clauses inside it. (Something more flexible and loose-coupling than Announcement would be really good, I agree.) -- Yoshiki