>>> I implemented a new announcer, which covers all functionality of the >>> original one >>> (all tests is green) but in addition enables you to subscribe directly via >>> #subscribe: >>> and receive #handle: message in case of announcements. >>> Of course, the decision whether to handle or ignore announcement is up >>> to subscriber. >> >> Can you give an example? I don't get it. > > you can subscribe using: > > announcer subscribe: object. > > and unsubscribe using: > > announcer unsubscribe: object.
Ok, now I get it. I wonder why this would be useful? Also it looks to me like very bad programming style, as the specification of what to handle and the handler itself are merged. You can do that also with the original API, but it is less encouraging because you have to hand in twice the same object into #on:do:. Also, have a look at the Exception API. Announcements solve a similar problem and provide a similar API. It would be a pity to break that similarity. I've never seen a single project that extended the exception API, there the simple message #on:do: is enough for everybody. > Please, can you elaborate, what you consider 'broken features' and why? > I am also not a fan of using flawed stuff. Weak objects are flawed in Pharo and Squeak. If you have an unbounded number of weak references it can quickly happen that the system spends 95% or more of the CPU cleaning up the weak references. For Seaside 2.8 we spent quite some time in getting rid of all weak references, afterwards we had a cleaner, easier to understand and much faster solution. > That's why i talking about limitations of weak block subscriptions. > While weak message subscriptions is easy to provide, using > WeakMessageSend. I guess you could copy the BlockClosure, no? Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
