On Tuesday, Jul 1, 2003, at 16:13 Europe/Zurich, Alexandre Bergel wrote:

> Hello Roel!

Hi Alex
I cut some stuff to make a reply a bit shorter :-)

> 2-Some comments:
> ---------------
> ---------------
> -Everything expressed with low events cannot be expressed with high 
> events. In your first example in the unit-test, a class is added in a 
> category: the high events does not provide any clue (except by 
> refering to the low event (original)) if the class is added or 
> removed. I think it is not an important issue. If anyone need to be 
> notified by such "low level" event, it just have to register to them.

No. You capture the high-level event, and ask it for its origin. This 
gives you to the basic event, so that you know why the high-level event 
was raised.
Besides, this way you can also find out very easily what basic and 
high-level events belong together in case you capture all of them and 
need to know this.

> -Have you thought about passing arguments?

Arguments are passed as instance variables of your event classes. I do 
not want to pass them as ad-hoc arrays, but objectified them in the 
Event classes.

> -The "changed event" is emitted first, followed by the "modified" one. 
> Why did you choose this order? According to my examples, it seems more 
> natural to the opposite order (i.e., first I would like to get 
> notified when a classbox is modified, and then look at the class 
> changed).

I chose to do it from the fine grained to the coarse grained: method is 
added, method is changed. class is modified.

> -the precedent point make me think about "how to design the client". 
> Right now, the client does not have any control on how to get 
> notified. Do you think we should provide a queuing mechanism? I am not 
> saying we should generalize that, but perhaps to provide some 
> easy-to-use mechanism.

?Can you explain some more? The clients now can choose what granularity 
of notifications they want (only basic, only high-level, all). The 
events are sent synchronously (so you know in what order they arrive). 
The client can give the selector used for the notification. What would 
you like more?

> -In the mailing list, I have seen there were some discussion about 
> having events synchronized or not. From my experience (I get with 
> mobile agents when I was working at INRIA), having asynchronized 
> events is difficult to handle... And right now I do not see any 
> convincing example for having them asynch.

It is a question of safety. I am looking into different strategies.

> -How do you handle changing a superclass?

Will need to add an event for that. In the meantime I already added 
some more (like for class comment changes), so it should not pose to 
many problems.

>
> I really like what you have done.

Just the start; more to come :-)


> Cheers,
> Alexandre
>
>
>
> On Tue, Jul 01, 2003 at 08:45:53AM +0200, Roel Wuyts wrote:
>> Hi guys,
>>
>> can you have a look at the stuff I sent around yesterday? If things 
>> are
>> not clear, then just write a mail or phone me on the following number
>> ++32 15 51 47 66. Or on my Swiss phone, but then it gets more 
>> expensive
>> for me :-)
>>
>> What I really want to know is whether you can use the 'higherLevel'
>> events or not. The idea is that clients can register to receive only
>> basic events (a class is removed, a method is added), or that they can
>> receive 'higher-level' events that are sent by the system after the
>> basic event (for example, when a method is removed from a class, I 
>> also
>> sent a 'class modification' higher level event). I think that this can
>> be useful, but tell me...
>>
>> PS: Note that I am at the hospital between 1:30 and 6 today, so I'll
>> not be available then.
>>
>> 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
>
> -- 
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.iam.unibe.ch/~bergel
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
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