Hi, > On Apr 20, 2016, at 9:37 AM, Henrik Johansen <henrik.s.johan...@veloxit.no> > wrote: > > >> On 19 Apr 2016, at 3:34 , Tudor Girba <tu...@tudorgirba.com> wrote: >> >> In the process I also added the possibility to remove Announcements from an >> AnnouncementSet and I would like to push this in Pharo 6.0. One thing I >> would work on is to add to Annoucements the possibility of filtering >> announcements based on instances not just types. This is a longer term plan. > AnnouncementSet is just a normal set, so it has always been possible to > remove items, just not recommended. > Filtering on instances is in the same category of making actual delivery > after subscription more dynamic; both also have the effect that it becomes > even harder to reason about what is going to happen as a result of an > Announcement without actually running the code.
The fact that AnnouncementSet is a Set is actually debatable because it basically reuses the implementation, not the type. Indeed, Set does allow for removing items, but I was referring to excluding items which is a slightly different use case (like is the case for Exceptions). > IMHO, if the logic is "I want to handle this announcement some of the time", > that is much easier to understand if handled explicitly in announcement > handling code, rather than through state changes to the announcement delivery. I disagree. I have a project which has about 50 different signals, and I am interested in all but one. Listing all 49 would be impractical and not particularly clear. Furthermore, when you have inheritance, it becomes even more complicated. You have the same case with exceptions and there we allow exclusions for good reasons. > As I think Glamour is a poster child for, current usage patterns can already > be hard to follow ;) I do not understand this statement in the context of this email. Cheers, Doru > Cheers, > Henry -- www.tudorgirba.com www.feenk.com "Reasonable is what we are accustomed with."
