[KCP] SystemChangeNotification: first blurb

Colin Putney cputney at wiresong.ca
Tue Jul 1 05:18:11 UTC 2003


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.

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?

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.

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

Cheers,

Colin



More information about the Squeak-dev mailing list