Yes, I have no idea about the performance of this idea at the moment. 
If there are too many events that are needed to make it work, then I 
will only send the 'basic' (non high-level) events. Clients that really 
need it can work from this, so maybe it is overkill. But let's wait 
until we have something running to get an idea.

Any ideas on how to properly benchmark this?

I nearly have a first implementation of a Notification system, not 
hooked up to the actual system - we can use this to test some things.

On Sunday, Jun 29, 2003, at 16:26 Europe/Zurich, Daniel Vainsencher 
wrote:

> Ok, I'll wait to see some code, and give you some more well grounded
> comments.
>
> Just hope that the proliferation of needed events don't get you bogged
> in constant changes to the Kernel/UI where these things are 
> generated...
>
> Daniel
>
> Roel Wuyts <wuyts at iam.unibe.ch> wrote:
>> No problem, we are in sync (this is what I meant with my reply - it
>> depends on whether anybody needs to know about this. Because if you 
>> do,
>> and it is not there, then things get ugly :-(  ).
>>
>> And no problems of it stopping me: I am happily implementing some 
>> first
>> things :-) I'll send a first code blurb as soon as possible (just to
>> give some ideas).
>>
>> Bring it  on :-) :-)
>>
>> On Sunday, Jun 29, 2003, at 14:55 Europe/Zurich, Daniel Vainsencher
>> wrote:
>>
>>> Roel Wuyts <wuyts at iam.unibe.ch> wrote:
>>>> On Saturday, Jun 28, 2003, at 22:35 Europe/Zurich, Daniel 
>>>> Vainsencher
>>>> wrote:
>>>>> - 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.
>>>
>>> Just some things to think about -
>>> If you consider methods to be merely behavior of a class, then method
>>> recategorization shouldn't bring up any events at all, because 
>>> behavior
>>> hasn't changed. This is correct, because it is a view that might be
>>> useful for some applications (concerned with behavior) but it isn't
>>> complete, because other applications are interested in structure
>>> (MudPie), which does change. So maybe having events for both
>>> complementary perspectives is the only way to serve all those needs.
>>>
>>> While most applications could be written successful to deal with
>>> recategorization encoded as remove/add, consider that this loses
>>> information, and then applications might need to start interpreting 
>>> the
>>> event stream to know what really happened (was that really removed, 
>>> and
>>> I need to run that classes tests again, or was it merely moved?). So 
>>> it
>>> might be better to consider a richer abstraction of possible events.
>>>
>>> Note that I don't want these meandering thoughts to stop you from
>>> starting to implement something coherent and simple, I just thought 
>>> I'd
>>> complicate things a little before triage begins...
>>>
>>> Daniel
>>>
>>>
>> 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