Hi Eliot,

Le 13/06/2015 06:54, Eliot Miranda a ��crit :

Hi Thierry,

On Jun 11, 2015, at 8:16 AM, Thierry Goubier <thierry.goubier@gmail.com
<mailto:thierry.goubier@gmail.com>> wrote:

2015-06-11 16:49 GMT+02:00 Ben Coman <btc@openinworld.com
<mailto:btc@openinworld.com>>:


�� �� Just a *very* divergent thought that I'm not sure is a good idea...
�� �� maybe the parent announcement could hold the announcer of its
�� �� children.


The problem is then that all tools which are not interested in the
parent announcement because they only deal with the low level stuff
(system browser, RPackageOrganizer and friends: MessageList, Spotter,
Critics browser, Finder, Versionner, Inspector, anything which listen
to a code change basically) have to still listen to the parent and, on
reception, subscribe to the low-level announcement, and then
unsubscribe on the parent end announcement.

It seems to me that with Ben's suggestion there need only be the
low-level announcement, and that subscribers interested in the
higher-level context could fetch it by asking the announcement for its
context.

I reacted to the fact Ben said announcer, not announcement... Reregistering announcers in code-aware tools is not something you do often [1]

One aspect I forgot is the performance issues linked with announcements. On package loads, a huge number of announcements is generated, and just simple things like tracking those to refresh the display of a system browser needs to be optimised to avoid degrading performance significantly.

Thierry

[1] https://github.com/ThierryGoubier/AltBrowser/blob/pharo5/Alt-Browser.package/AltBrowser.class/class/registerOnSystemAnnouncements.st