On Tuesday, Jul 1, 2003, at 07:18 Europe/Zurich, Colin Putney wrote:

> Hi Roel,
>
> Nice work! I really like the overall design, particularly the public 
> protocol of the SystemChangeNotifier. This going to open up a lot of 
> possibilities for improving the Squeak development tools.

I sure hope so...

>
> However, looking over the event classes made me wonder if the 
> high-level notifications are really necessary. As far as I can tell, 
> the immediate clients of SystemChangeNotifier are all going to need to 
> catch all the basic events, and either don't need or already have 
> facilities for working out their corollaries. Would you mind 
> explaining the perceived need for the high-level events that led you 
> to put them into the model?

I was thinking about the following:
Consider that you are implementing a cache that caches certain 
information regarding methods. You keep a method representation as key 
in an internal dictionary in the cache, with your information as 
values. Then you need an invalidation scheme for the cache. You need to 
update the cache whenever a method is added or removed, possibly when 
it is renamed (depending on the key for the method), or when a class is 
added, removed or renamed (again depending on the key for the method), 
etc.

One possibility is to register to receive all the basic changes 
(additions, removals, renames, ...), and work from there. This is 
clearly possible, and even quite simple for this example.

But another possibility is to only get the high-level events that 
indicate a high-level change to a method or a class. This reduces the 
number of changes to react to to two: a method change (regardless of 
whether it is an addition, a recompile a remove, ...) and a class 
change. Then the cache can be invalidated.

>
> My concern stems from the fact that they add a significant complexity 
> cost to the event model. For example, I noticed that you have 
> SystemModifiedEvent as a subclass of SystemHigherLevelEvent. In the 
> case of "category modified" events originating from class additions or 
> removals, this is exactly right. But what about basic modifications, 
> such as reshaping a class or recompiling a method? You could make a 
> SystemBasicModified event for this, but where would it fit in the 
> hierarchy? The fact that there are several orthogonal properties for 
> each event makes it difficult to model with a tree of classes, and it 
> could easily turn into the kind of "strange" hierarchy that we have 
> with Collections or Streams. There's also a complexity cost to 
> clients, of course, and that's potentially more of an issue.

Agreed with the complexity, but not with the danger for orthogonality 
problems. I decomposed according to the change event type, since this 
is what is triggered anyway. And one criterium for the events is that 
they cannot be basic and higher-level at the same time. So I don't 
think we'll run into problems there.

So to have higher-level events or not will depend on the clients: are 
there enough users that only need the higher-level events (and whose 
code consequently becomes easier) to warrant the extra complexity? I am 
thinking about this at the moment, so any input is welcome!

> Anyway, I thought I'd bring this up now, while it's easy to make 
> course corrections.

Yes, that was the intention of producing something quickly, so that I 
can get feedback from my 'clients' early in the process :-)

>
> Cheers,
>
> Colin
>
>
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