On Saturday, Jun 28, 2003, at 22:35 Europe/Zurich, Daniel Vainsencher 
wrote:

> A couple of questions -
> - What are your current thoughts on order? does the event comes
> before/after/during the changes? does the higher level changed event
> comes before/during/after the specific added change? or is undefined?

The event comes 'after' the changes. Maybe afterwards I will add 
another set of notifications for 'before' the change.

I plan to send the higher level event after the specific one, unless 
you can convince me otherwise :-) But clients should (and will) be able 
to choose what events they get (all of them, including the higher 
levels ones, or only the 'regular ones).

It is definetely not undefined if I can help it :-)


> - What does a method/class recategorization trigger?

Good question, since it is essentially a 'move'. So I guess it should 
do a removal/addition pair. Or maybe a separate event. It depends on 
whether anyone needs to know specifically about recategorization.

>
> All looks good to me, btw.
>
> Daniel
>
> Roel Wuyts <wuyts at iam.unibe.ch> wrote:
>> Hello, I am playing around a bit regarding the System Change
>> Notification. This is a first blurb I wrote regarding the events I'd
>> like to see there. I haven't really looked around whether this would
>> cover the existing system thingies (that is next on my list). So not
>> all of the 'kinds of events' are necessarily there yet, but it shows 
>> my
>> line of thinking, I hope. As always: any comments on this early
>> proposal are welcome!
>>
>> Next up (planning):
>> - look what parts of the system can use this; maybe extend with 
>> certain
>> other things
>> - take any feedback into account
>> - look at exactly how to implement this with events (I am playing
>> around with them)
>> - implement unit tests
>> - start the implementation using events, for a limited number of
>> events; update ChangeSet to use this
>> - iterate
>>
>> --------
>> 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).
>>
>> Depending on the change type, certain information related to the 
>> change
>> is always present (for adding, the new things that was added, for
>> removals, what was removed, for renaming, the old and the new name,
>> etc.).
>>
>> Depending on the item type, information regarding the item is present
>> (for a method, which class it belongs to).
>>
>> 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.
>>
>> Note that we added 'composite events': wildcards for the 'change type'
>> ('any' - any system additions) and for the 'item type' ('Changed' - 
>> all
>> changes related to classes), and one for 'any change systemwide'
>> (systemChanged).
>>
>> This result is this list of Events:
>>
>> classAdded
>> classRemoved
>> classModified
>> classRenamed (?)
>> classChanged (composite)
>>
>> methodAdded
>> methodRemoved
>> methodModified
>> methodRenamed (?)
>> methodChanged (composite)
>>
>> instanceVariableAdded
>> instanceVariableRemoved
>> instanceVariableModified
>> instanceVariableRenamed (?)
>> instanceVariableChanged (composite)
>>
>> protocolAdded
>> protocolRemoved
>> protocolModified
>> protocolRenamed (?)
>> protocolChanged (composite)
>>
>> poolVariableAdded
>> poolVariableRemoved
>> poolVariableModified
>> poolVariableRenamed (?)
>> poolChanged (composite)
>>
>> categoryAdded
>> categoryRemoved
>> categoryModified
>> categeryRenamed (?)
>> categoryChanged (composite)
>>
>> anyAdded (composite)
>> anyRemoved (composite)
>> anyModified (composite)
>> anyRenamed (composite)
>>
>> anyChanged (composite)
>>
>> 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...
>>
>> To check in the current Squeak: we might have to accomodate a number 
>> of
>> events that do not fit the scheme proposed. Or new kinds of items or
>> changes.
>>
>> --
>> 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
>
>
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