At Sun, 1 Nov 2009 19:35:57 +0200, Igor Stasenko wrote: > > 2009/11/1 Lukas Renggli <reng...@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 _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
