SystemChangeNotification comments

Nathanael Schärli n.schaerli at gmx.net
Tue May 17 08:51:04 UTC 2005


Hi Alex,

Thanks a lot for looking into this. Here are some thoughts about your
comments:

>   - Events have to be emitted __AFTER__ the action occurs. 
> Roel always that that rules in mind, which makes sense. 
> However, this order is inverted when a class is removed. Look 
> at SystemDictionary>>forgetClass:logged:, the event emission 
> occurs before the removal.

I think that the reason for this is "historical". This means that Roel
just put the calls to the SCN at the place where the direct calls to the
changeset/changelog used to be.
While this did not seem to be problematic so far, I think that it would
be nice to make this consistent in the (near) future. However, when we
do so, we should evaluate whether it might not be better to extend the
framework so that we get notifications before _and_ after the action
occurs. (The _before_ notification has the advantage that it is still
possible to make sure that everything is consistent or cancel the
action).

>   - The original version of SCN, when a set of instance 
> variables are added, several events are emitted, one per 
> variable. In the new version, just one modified event is 
> emitted. I do not know which of these two way is better. Need 
> help for this point...

Yes, this is one of the few changes I implemented. The reason is that by
editing the class definition, several class format changes (new instance
variables, new superclass, new class variables, etc.) can happen at
once. Therefore, it is more practical to have a single notification for
such a set of changes rather then having a several independent
notifications that occur in arbitrary order.

If you have more questions/comments just let me know.

Cheers,
Nathanael


> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of Alexandre Bergel
> Sent: Freitag, 13. Mai 2005 23:33
> To: squeak-dev at lists.squeakfoundation.org
> Cc: Roel Wuyts; Nathanael Schaerli
> Subject: SystemChangeNotification comments
> 
> 
> Hello,
> 
> Roel did some tests for his system change notification (SCN). 
> However, the tests need to be adapted because the SCN has 
> improved since. For instance, Nathanael did some 
> refactorings. Because the SCN is a critical part of Squeak, 
> currently I am adapting the tests that Roel did for the 
> current version of SCN.
> 
> I also discovered some weakness in the current system. Before 
> submitting anything, I would like to share some thoughts:
> 
>   - Events have to be emitted __AFTER__ the action occurs. 
> Roel always that that rules in mind, which makes sense. 
> However, this order is inverted when a class is removed. Look 
> at SystemDictionary>>forgetClass:logged:, the event emission 
> occurs before the removal.
> 
>   - Regarding a remove event, what are the informations that 
> an event should carry? If I remove a class, do the event have 
> a reference to this class then? If yes, then the class is 
> removed from the system, an event is triggered and this one 
> have a ref to the just-removed class. IMHO, this schemas 
> makes sense because an event should carry the right amount of 
> informations such that a client does not prefer to receive 
> this event before the action occurs.
> 
>   - The original version of SCN triggers a DoIt event _each_ 
> time the user perform one. In that case, the event has the 
> information if it should be logged or not. In the new version 
> of the SCN, a doit event is emitted only if it should be logged.
> 
>   - The original version of SCN, when a set of instance 
> variables are added, several events are emitted, one per 
> variable. In the new version, just one modified event is 
> emitted. I do not know which of these two way is better. Need 
> help for this point...
> 
> Cheers,
> Alexandre
> 
> -- 
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.iam.unibe.ch/~bergel 
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> 
> 




More information about the Squeak-dev mailing list