Now I would also like to know the cost of always broadcasting. I do not remember correctly but in vassili'blog there were some points to avoid that.
Yes, broadcasting was the reason why OBPackageBrowser was slow before we refactored it.
Actually, the sloppiness came from the handlers associated to events. They generated way too many refreshes. Broadcasting events did not appear to be that slow. Users of an event mechanism have the tendencies to broadcast events more than it should be. Alexandre
On Oct 31, 2009, at 11:18 PM, Lukas Renggli wrote:
In current core image, Announcements is quite small (just around 10 methods totally) and i doubt it provides enough flexibility which would not require adding & reinventing additional useful stuff on top of it.
I have used these announcements in many large projects and I never needed to add anything. In fact, I would even vote to remove AnnouncementSet as I never used it or saw it used anywhere. Initially, I found it cool because the same trick is applied in the Exception hierarchy. Major projects like OmniBrowser (and to some extent also Seaside) use an even smaller subset of the functionality provided in the core package.
The only thing that is maybe missing are weak announcements. I guess that could be useful, if Pharo provided a solid implementation of weak objects.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.