2009/11/1 Yoshiki Ohshima <[email protected]>:
> At Sun, 1 Nov 2009 19:35:57 +0200,
> Igor Stasenko wrote:
>>
>> 2009/11/1 Lukas Renggli <[email protected]>:
>> >> 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
> [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
