Hi Thierry,

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



2015-06-11 16:49 GMT+02:00 Ben Coman <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.


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