2009/11/1 Yoshiki Ohshima <yoshiki@vpri.org>:
At Sun, 1 Nov 2009 19:35:57 +0200, Igor Stasenko wrote:
2009/11/1 Lukas Renggli <renggli@gmail.com>:
Oh, wait.. you mean that if i want, say 35 out of 50 announcement kinds to be logged, then i need to do something like:
logblock := [:announcement | ... ]. announcer on: AnnouncementKind1 do: logblock. announcer on: AnnouncementKind2 do: logblock. .... announcer on: AnnouncementKind35 do: logblock.
? Do you agree that this is far from being short and elegant? Moreover it imposes dependency from various kinds of events, instead of just one (LoggedAnnouncement), and, if i going to change them somehow, i would need to revisit this code again.. and again.
  announcer     on: AnnouncementKind1 , AnnouncementKind2 , ... AnnouncementKind35     do: logblock
good catch. Still dependency on 35 classes .. while my intent is to subscribe to all announcements which can be logged. If i load new package, it could provide more announcements which can be logged. But i will not be able to see them if i'm going to enumerate them in such way :(
 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.
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. I think that this part of discussion can be closed. 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.
-- Yoshiki
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.