Hi Thierry, On Jun 11, 2015, at 8:16 AM, Thierry Goubier <thierry.goub...@gmail.com> wrote:
> > > 2015-06-11 16:49 GMT+02:00 Ben Coman <b...@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. > Another issue is, when introducing a new class of activity such as > SprintInRMOD, you then need to rewrite all the listeners to add the relevant: > ... on: SprintInRMOD do: [:a | a childAnnouncer on: MethodChange do: ... ] > > Kind of messy. > > For me, what Martin is trying to do is currently handled in a way by MC and > RB: write all your code operations as abstract operations on a model of the > code, group them into a composite (RBCompositeChange or something like that), > and apply them all in one go. But all this structure is flattened in the > change set, and may be interleaved with other changes happening at the same > time. > > I'd take Martin's job idea :) plus specific announcements for the start and > end. > > Thierry > >> cheers -ben >> >> > >> > I hope you can make some use of my ramblings (last exam tomorrow, just >> > taking a break here :) ) >> > >> > Cheers, >> > Max >> > >> > >> > >> > Kind regards, >> > MartÃn >> > >> > >
