On Sunday, Jun 29, 2003, at 13:20 Europe/Zurich, Stephane Ducasse wrote:

>> Are there any events that you would need and that are missing?
>
> Packages? ;)
> Have you thought of how to get new entities :)

Of course :-)

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

Was next on my to-do list anyway.

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