[skipped lots of other interesting stuff]
 
> The only real flaw we've noticed in this approach so
> far is the requirement it imposes on each tool to
> signal the appropriate events; in the case of the
> standard Squeak release, this required minor "touches"
> on about 20 methods, viz., those methods which are
> invoked when code's saved.  This is relatively
> painless, and in any case invisible to the intrepid
> Squeaker, BUT it will give nasty surprises when
> tools/browsers/etc. which have not been "touched"
> enter into the system.

I had the same problem in some work I've done. I also did not want to change
any existing tool. An extra constraint was that I wanted it to work in
Squeak, VisualWorks2.5, 3 and Envy4.

I solved it by implementing a listener that uses the ChangeSet for the
majority of changes (very practical, that ChangeSet, works even in Envy :-)
), and some methods implemented at the class side of Object (for changes not
being captured by the change set, or at the wrong moment). This solution
works flawlessly: regardless of the tool you use (yes, also the refactoring
browser) you can follow anything that happens in your system.

I wanted to make it public separately from the system I use it in (it's a
separate Envy application anyway), so if you need it I'll try to put that
higher on my priority list :-)


--
Roel Wuyts                           Software Composition Group
Roel.Wuyts at iam.unibe.ch         University of Bern, Switzerland
Board member of the European Smalltalk User Group: www.esug.org