Can one of you turn the following list into bug entries? So that we can make progress by killing them one by one?
Stef >>>> agreed here. I would even leave a semaphore. >>> I think it is overlooked by Henrik. >>> It also don't needs a lazy initialization in #protected: , since in >>> #initialize it can just create a ready for use fresh >>> synchronization object. > > A semaphore might block, because an announcement could register > another announcement. So probably the Mutex would be the right thing > to use. But apparently Mutex is broken :( > >>>> 4. It creates a copy of the collection of all the subscriptions: This >>>> is rarely useful and wouldn't be necessary if an immutable data >>>> structure was used. >>>> >>> propose better solution how to deal with situation when during >>> handling an announcement, >>> your handler unsubscribing from announcer. > > Array. Slower for registration, but faster at announcing (the common > operation). > >>>> 5. It iterates over all announcements, it doesn't even try to group >>>> announcements of the same kind. >>>> >>> it is pointless to group them, and makes no real difference. >>> Because announcer doesn't knows what kinds of announcements will be >>> announcement, >>> and it knows only about subscriptions. >>> Suppose i have a subscription to Announcement. And i announcing >>> AnnouncementA (a subclass of it). > > Fair enough, probably it doesn't matter. > >>>> 7. It then tests each announcement if it matches, again it doesn't >>>> even try to group the announcements of the same kind. Aside, the match >>>> test was changed so that it doesn't allow instance-based announcements >>>> anymore, breaking some of my code. >>>> >>> what is instance-based announcements? > > If you have a client with 1000 different possibly dynamically changing > properties and you want a way to register for announcements of a > single property. The current implementation forces you to create a > class per property, previously you could fake a "kind of > announcements" with an instance. > >>> you can use any object as a subscription selector, just make sure it >>> understands #handles: message. >>> i.e. > > No, because the Announcement>>#handles: takes a class, not an instance. > >>>> 9. It then culls the announcement and announcer into the block. Not >>>> sure why the announcer is useful, after all the block was registered >>>> with the announcer at some point. >>>> >>> cull there is for passing optional arguments. > > I didn't complain about #cull:, but about the useless announcer passed in. > > Now for me you don't need to change the semantics of the Pharo > Announcements again. Now for my code I will just use my own > implementation that has exactly the behavior and performance > characteristics I need. Lukas our state of mind is that we want the infrastructure gets better so we like to change for a better one if this better one is better. If everybody has its own version then we do not improve the infrastructure. Stef
