Ok, first of all I did not know who wrote the code. I was just fixing some of my code that suddenly broke and was astonished what the announcer all does when stepping through the announcement procedure with the debugger ...
>>> 3. It enters a critical section of a monitor: This is rarely useful >>> and the slowest kind of concurrency control available in Pharo (a >>> Mutex would be enough for what it is used for, and instantiate >>> multiple semaphores and queues), and btw the lazy initialization of >>> the monitor is the prime example of a race condition. >>> >> 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. >>> 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 -- Lukas Renggli www.lukas-renggli.ch
