2009/11/2 Yoshiki Ohshima <[email protected]>: > 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. > yes.
>> > 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". > Sure thing. >> 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. > the #handle: is an entry point, where subscriber could decide what to do with announcement. And of course, you can introduce messy testing code if you need. But its up to you, not up to Announcement framework. See the difference? My point is, that #isKindOf: test is not always single one or best one, which can be used to test the relevance of announcement to subscriber. We having a Traits, right? Now imagine that i could control, whether announcement can be logged or not, by simply using or not using a trait in my announcement subclasses. It can be even a trait with no methods, but i can use this information to check if given announcement is relevant to my subscriber. And as result: zero new methods, no extensions to core and very convenient way to promote announcement to be a logged one. Just one requirement: give me a way to define own means to check the relevance to subscriber :) > (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 > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
