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