On Saturday, June 28, 2003, at 06:00  AM, Roel Wuyts wrote:

> We propose two orthogonal groups to categorize each event:
> (1) the 'change type':
> 	added, removed, modified, renamed
> 	+ the composite 'changed' (see below for an explanation)
> (2) the 'item type':
> 	class, method, instance variable, pool variable, protocol, category
> 	+ the composite 'any' (see below for an explanation).
> The list of supported events is the cross product of these two lists 
> (see below for an explicit enumeration of the events).

That sounds to me like it covers all the possibilities. My interest in 
this relates to PackageInfo and Monticello, which need all these events.

> Certain events 'overlap', for example, a method rename triggers a 
> class change. To capture this I impose a hierarchy on the 'item types' 
> (just put some numbers to clearly show the idea. They don't need 
> numbers, really. Items at a certain categories are included by items 
> one category number higher):
> level 1 category
> level 2 class
> level 3 instance variable, pool variable, protocol, method.
>
> Changes propagate according to this tree: any 'added', 'removed' or 
> 'renamed' change type in level X triggers a 'changed' change type in 
> level X - 1. A 'modified' change type does not trigger anything 
> special.
> For example, a method additions triggers a class modification. This 
> does not trigger a category modification.

When this happens, do clients receive both events or just one? The 
model I'm imagining is that all clients are notified of each change to 
the system only once, and they receive the most specific Event they 
have registered for.

> anyAdded (composite)
> anyRemoved (composite)
> anyModified (composite)
> anyRenamed (composite)
>
> anyChanged (composite)

I think it would be better to name the composite item type 'system' 
instead of 'any'. The meaning of the resulting events is a little more 
apparent when encountered in isolation (ie, not in the context of a 
list of events). So then you have the following events:

systemAdded
systemRemoved
systemModified
systemRenamed
systemChanged

By the way, what do the question marks next to the renamed events 
signify?

> To check: can we pass somehow the 'source' of the change (a browser, a 
> file-in, something else) ? Maybe by checking the context, but should 
> not be too expensive either... I found this useful in some of my 
> tools, but it might be too advanced to have in general. Tools that 
> need this can always write code to check it for them.  But is not 
> always simple...

What you've proposed is such an enormous improvement, that I wouldn't 
worry about this. I agree that it's useful, but I think you're right 
that it would not be simple. Let's wait until someone actually needs 
this before tackling it.

Sounds like a good plan, Roel!

Colin