2009/11/2 Lukas Renggli <[email protected]>: >>>> 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.
there is no specification what to handle, because in my implementation the Announcer doesn't having any knowledge about nature of subscriptions. Its only task is to broadcast the announcement to all subscribers without any extraneous logic - consider an observer pattern in its purest form. Then there are a special kind of subscription, which handling announcements in style which were originally made for Announcer. And finally, i could turn your own argument back to you: why its Announcement deciding whether subscriber interested in it or not, by implementing checks in #handles: method at class side? Isn't this a mixing of 'what to handle' and 'handler' roles? > 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:. > passing twice? I think you meant passing once, i.e.: announcer on: Announcement do: self which can be a roughly equivalent to announcer subcscribe: self. except that this case you will need to implement own #valueWithArguments: and #receiver methods while in my variant - #handle: , and except that current framework will do unnecessary #isKindOf: checks before delivering announcement to such handler. > 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. > but there is #on:do:! So, if one think its enough for him - no problem just use it, and forget about #subscribe:. How it breaks the similarity (which i find good myself btw), when it providing same functionality as current one? By enabling more generic form of subscription? Oh cmon... >> 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. > i don't expect too many subscribers to a single announcer (do you?), and the number of weak ones could be even less than that. I think that if announcer keeps more than 10-20 subscribers, it will already a signal that you start abusing framework. :) So i don't think that cleaning it up will be an issue or bottleneck in this case. And of course i am aware of potential pitfalls of weak finalization in squeak. But hey: we don't care about managing memory in smalltalk, why we should abandon idea to have an automatically managed weak subscriptions? Since you usually never send #dispose/#free for each corresponding #new, it is logical to have an option to never send #unsubscribe: for each corresponding #subscribe: , isnt? It imples some discipline? Yeah. As well as #new does, because if you attempt to allocate memory in a run-away fashion, you will end-up with memory overflow. >> 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? > This will give nothing. The problem that BlockClosure holding all references strongly, as well as any context object. And even worse - the real subscriber (our object of interest) is not held directly by a closure, but by its home context object. And there is no guarantees that given context's state keeps reference to subscriber only in 'receiver' slot. It could be kept in temps or temps could reference the receiver etc etc. And you can't hold a BlockClosure weakly, because it will vanish once you exit from #on:do: method. So, the only solution is to keep it strongly as long as receiver are referenced strongly by something outside the BlockClosure references subgraph. This is what ephemeron does, but its impossible to implement using weak refs. > 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 > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
