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