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. 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? -- Yoshiki