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

Packages? ;)
Have you thought of how to get new entities :)

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

Roel I would like you to have a brief look at Changeset and related 
class (browse fileout methods) and fileout in classDescription so that 
we get in sync. I think that lot of logic in there is working but so 
difficult to follow. Especially for the fileOut. I would like to 
discuss that once because nathanael and alex may need to change that 
for their work and this is not easy.


Stef