I'll keep it in mind and have a detailed look at existing users first 
(wanted to to that anyway, but should have said so).

Note however that the implementation is actually 'quite' simple, and I 
have it working (a limited version) in VisualWorks. So most of the code 
(and tests) I can just reuse and extend. The reason I wanted to wait to 
refactor ChangeSet to use this new mechanism is that I was a bit afraid 
to tackle it from the start, because it is hard to work on while 
changing it. So I first wanted it to be a bit stable.

OK, let me update the proces a bit:
1- I'll have a detailed look at existing mechanisms and usages in 
Squeak and summarize to the mailing list (PS: Any suggestions are 
welcome! If you know of any not-quite-obvious-tools or mechanisms: 
please send me a mail !!! ). Part of this description will be a list of 
events that will be supported (yes Andreas, I'll use the events 
mechanism).

2- Port my VisualWorks thingie and adapt/update it to cover the 
existing usages. Release first implementation that only captures a 
restricted number of events. Summarize design of the implementation to 
the mailing list.

3- Update the changeset to use these first events.

4- Iterate until complete (e.g. all events from step 1 are covered and 
the ChangeSet only uses events.


A final note: I will not start implementing/working on this until next 
week (unless I cannot restrain myself, like today :-) ).

On Tuesday, Jun 24, 2003, at 17:00 Europe/Zurich, Daniel Vainsencher 
wrote:

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

That is exactly the kinds of things I was thinking about :-) Great.

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