> On 20 Apr 2016, at 9:54 , Tudor Girba <tu...@tudorgirba.com> wrote: > > 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. I agree, it would be better if AnnouncementSet didn't inherit the full Set API. > 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).
Ah, exclusions are a different matter from removal, that sounds like a good change indeed! My point was, messing with the subscription to alter what is being delivered outside of registration/de-registration, would lead to hard(er)-to-understand code; that's would not be the case for exclusions like: announcer when: SuperAnnouncement - SpecificAnnouncementImNotInterestedIn do: [:ann | ... ] Cheers, Henry
signature.asc
Description: Message signed with OpenPGP using GPGMail
