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...