[KCP] Thoughts on adding system changes and refactoring ChangeSet

Andreas Raab andreas.raab at gmx.de
Tue Jun 24 13:36:18 UTC 2003


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

Definitely use the event mechanism. It has been built for purposes just like
this.

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of Roel Wuyts
> Sent: Tuesday, June 24, 2003 3:15 PM
> To: squeak-dev lists.squeakfou
> Subject: [KCP] Thoughts on adding system changes and 
> refactoring ChangeSet
> 
> 
> 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
> 
> 



More information about the Squeak-dev mailing list