Wrote comments in between the mail, so you have to scroll a bit :-)

On Saturday, Jun 28, 2003, at 20:44 Europe/Zurich, Colin Putney wrote:

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

Are there any events that you would need and that are missing?

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

I'd like the clients to be able to choose this, since I had need for 
both things (not too hard with the event system luckily). What you 
describe is one example of a 'notification policy', which is also 
needed for example by the ChangeSet. But I think other policies might 
be needed. If I can't find concrete examples in the current system, 
I'll only implement the current one. I want to make it very easy to 
specify the list of events clients can get anyway...

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

Yes, I thought about the same yesterday but prefered any... I'll wait 
with choosing before writing down some tests and seeing what 'looks' 
and sounds good :-)

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

I am not sure I can easily implement them at the moment, so I wanted to 
check first. It is of course possible to implement, and I think it is 
needed, so I'll probably implement them.

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