I am very glad you are tackling this. This can result in many wonderful
kinds of tools being easy to implement efficiently, because it allows
precise information to be cached -
* senders of can be instantanous
* string used in methods
* MudPie will not have to rescan the image, which is the slowest part in
it's operation (half a minute)
* This could be used to make package systems, like DVS, be able to note
and completely revert/review changes made to packages

And so forth. 

About implementation - I know you designed the process in a way that is
convinient. OTOH, it is an order that seems to leave all the risk to the
end - a big bang integration. 

I think you should consider doing it exactly in reverse - first study
and summarize the state of existing mechanisms and clients in Squeak,
and propose a refactoring such that stuff will go through your
mechanism. If something must be broken, we'll find out fast and decide
what to break when. 

This stage will also allow the community to give you concrete feedback
on the interfaces, policies and mechanisms, as early as possible, and
before you implement too much functionality to change.

Then continue to add functionality and options on this base.

Daniel

Roel Wuyts <wuyts at iam.unibe.ch> wrote:
> Hello,
> 
> As part of the KCP effort I want to add something to Squeak that I 
> think is terribly important (having something send system change 
> notifications around). In this mail I want to motivate why I think this 
> is important, how I envision it will impact ChangeSet, how I see the 
> implementation process, and some more technical questions I need your 
> help with.
> 
> --------
> 1 Motivation
> Whenever somebody asks me for the Smalltalk killer application, I tell 
> them: the development environment. It employs all the sophisticated 
> features available in the languae, and puts them to good use. It shows 
> that Smalltalk truly is a reflective and highly dynamic language. There 
> is however one thing in most Smalltalk environments that I find 
> absolutely revolting: 'update' (or 'refresh') buttons. What I don't 
> like is that as a user you are sometimes forced to use them to bring 
> your tool back in sync with your code. In such a nice dynamic 
> environment, this is a crime. But what is a developer to do when 
> changes to the system are not propagated to the place where they are 
> needed?
> 
> What I see as a solution to this problem, and have implemented already 
> in VisualWorks/Envy in a previous lifetime, is some entity that sends 
> notifications around about system changes, such as 'method VVV was 
> added' or 'instance variable LLL was removed' or ... And yes, I am 
> aware that the Changeset already provides a kind of solution to this 
> problem: you can register yourself as a dependent of the changeset and 
> receive a number of these notifications. However, there are two 
> problems associated with this approach: (1) the set of notifications is 
> not complete, and (2) some notifications are sent before the change 
> occurs, some halfway, and some after the change is applied. The last 
> problem makes it difficult for tools to use this trick. For example 
> (this is in VisualWorks, but you can find similar examples in Squeak - 
> haven't checked yet), when adding the method, you get the change when 
> the method is compiled, but before it is added to the method dictionary.
> 
> Note also that such system notifications are not only useful for the 
> current browser, but are very useful in other tools as well. For 
> example, traits will use this to know when they need to update certain 
> method dictionaries. I used it before to invalidate certain system 
> caches.
> 
> So I want to add such a feature to Squeak so that tools can take full 
> advantage of this, and change the ChangeSet to use this feature. 
> Initially, the ChangeSet, Traits and Classboxes will be my clients, so 
> that I get some concrete feedback from people using it.
> 
> --------
> 2 Impact on ChangeSet and the rest of Squeak
> Now ChangeSet is the one that gets called from several places to get 
> notified of a change, and it in turns broadcasts these system 
> notifications to its dependents. In the setup I envision, the new 
> SystemChangeNotification will be the central part, ChangeSet will be 
> one of the clients that receives notifications from 
> SystemChangeNotification.
> 
> 
> --------
> 3 Implementation process
> - I first plan to add a completely stand-alone implementation of 
> SystemChangeNotification, and write tests for it (I have Unit tests 
> from VisualWorks that I can use for this). This first implementation 
> will send notifications after the change has been done. So dependents 
> receiving an 'method-has-been-added' notification will get this after 
> the method was added, etc.
> - once this implementation is stable (and I get some feedback from the 
> traits and classboxes, that should use it), I might extend the 
> implementation to also provide notifications before a change occurs 
> (with the possibility to not do it at all). The decision on whether or 
> not to do it will depend on possible users of this feature. I might 
> also make this extension at the end of the process
> - once it is implemented and is reasonably stable, I will change the 
> CangeSet to use the SystemChangeNotification. This is actually the 
> difficult part of the work.
> 
> --------
> 4 Questions
> I have a couple of questions that I'd appreciate help with.
> 1- In VisualWorks I used the 'regular' dependency mechanism: 
> SystemChangeNotification was a model, users could make themselves 
> dependent on this and receive notifications of change. However, there 
> are now alternatives to this (the 'event' mechanism). I am not really 
> aware of the differences, and before choosing one of either approaches, 
> I'd appreciate any comments on which one might be best to choose. Any 
> ideas?
> 
> 2- Hmm, only question at this moment. So, shoot!
> 
> --
> Roel Wuyts                                                   Software 
> Composition Group
> roel.wuyts at iam.unibe.ch                       University of Bern, 
> Switzerland
> http://www.iam.unibe.ch/~wuyts/
> Board Member of the European Smalltalk User Group: www.esug.org