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. Because in the past, in Smalltalk the dependency where broadcasting to all the dependents and this was inadequate and after they introduce on:when:..... to get only the right listener updated.
Yes, broadcasting was the reason why OBPackageBrowser was slow before we refactored it. Mondrian and OBPackageBrowser are happy with the current Announcement infrastructure. Cheers, 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.