Confused about SystemChangeNotification

Roel Wuyts Roel.Wuyts at ulb.ac.be
Fri May 6 12:35:45 UTC 2005


Hi y'all!

I provided unit tests to sort out these things. I remember that I 
triggered a category-changed event for classes, for example, which I 
tested. All kind of renaming or removal events passed a string with the 
old name as argument, in case you needed to know. But I do not know 
what exactly Nathanael refactored, what parts got removed, etc.

So I wanted to check my unit tests but I could not find them in the 
stock 3.7 image that I downloaded. I can have a look at the code if 
someone can point me in the right direction.

PS: I remember some problems with class renames in general in 3.6 that 
I had to work around. I submitted a separate bugfix for this (there 
were some problems there). The system event changes were meant to be 
used in a Squeak where these patches were applied. Maybe they got 
added, or got added in a different fashion, and the change mechanism is 
unhappy about it. Again, the unit tests should show this (they used to 
fail in an image where these class-rename-patches were not loaded).

Regarding the 'design' of the system: I considered the unit tests the 
most important part of the implementation. Regarding the design itself: 
I started out with a more complicated system, but simplified it in the 
end. In the more complicated system I had general events and specific 
events. The specific events knew the general event they belonged to. 
Clients could register for all events, general events, or specific 
events. For example, some clients that keep a cache are interested in 
very fine-grained events (as it is now). But some other ones could do 
with a coarse-grained approach. After discussing with several people 
about this at Camp Smalltalk in Bled (Slovenia), I decided to only keep 
the fine-grained model. But of course I agree with Nathanael: this was 
not meant to be, nor is it, the 'perfect' solution.

On 02 May 2005, at 10:11, Nathanael Schärli wrote:

> Hi Stef and Andreas
>
>> I asked nathanael to reply since he refactored roel's code.
>
> Well, the word "refactoring" is maybe a bit too much. What I did was
> fixing whatever was necessary to make it actually work. However, the
> idea and structure of the framework is still Roel's. So, he should know
> the most about why he took certain design decisions.
>
>>> a) When I compile a method in another category, no recategorized
> event
>>> is generated. Why? It is impossible to find out where a method "came
>
>>> from" when using the modified event. This is easy to fix since the
>>> code in ClassDescription>>addAndClassifySelector: selector
> withMethod:
>>> compiledMethod inProtocol: category notifying: requestor explicitly
>>> suppresses this notification. But the question remains - why do it
> in
>>> the first place?
>
> I guess the reason is that this information is also not communicated in
> the older versions of Squeak. If a method is compiled in another
> category, the method
>
> Changeset>>noteNewMethod:forClass:selector:priorMethod:
>
> is called, and this also does not contain the information where a 
> method
> came from. Therefore, I think what happened is that Roel tried to
> "emulate" the old protocol and simply forgot that more information 
> (such
> as where the method "came from") would actually be very handy. I also
> didn't realize this when I integrated the code afterwards because I was
> mainly fixing bugs in an attempt to make sure that everything that used
> to work still works. (As I said above, I didn't add any new features 
> and
> also kept Roel's design/architecture as it was.)
>
> That said, I absolutely agree with Andreas that this information could
> be very useful and should be provided (especially, since it is quite
> easy to fix).
>
> (BTW: Note that in older Squeaks, things were even worse because
> recategorization events never occured. Thus, if a method was
> recategorized with drag and drop, the changeset was not informed at
> all.)
>
>>> b) When renaming a class the renamed event refers to the class under
>>> the old name. In other words, rather than getting our hands on the
>>> class under the name by which it is known in the environment we get
> it
>>> under the old name which no longer exists in the environment. Why?
>>> This is totally inconsistent - it exposes the fact that the
> invariant
>>> "aClass == aClass environment at: aClass name" is temporarily
> broken.
>>> Why?
>
> Also for this question I can't really give a final answer as it 
> concerns
> code from Roel. But again, I think the reason is that Roel's work is
> based on the older versions of Squeak, which shows the exact same
> artefact!
> In fact, in Squeak 3.6 (and earlier), there is a method
>
> Changeset>>renameClass: class as: newName
>
> which also gets called with the argument "class" still having the old
> name. So, I presume that Roel just replaced the call to this method
> (which happened in the Class>>rename:) with a call to the
> SystemChangeNotification mechanism. So, he kind of "inherited" this
> artefact.
>
> That said, I again agree with Andreas that passing a class with the 
> "new
> name" is safer and more consistent. Changing this should also not be 
> too
> hard. However, since this is strictly speaking not a "fix" but a
> "change", we need to make sure that none of the existing code actually
> relies on the historic/traditional way of doing things.
>
> Last but not least, I would like to say that while I'm convinced that
> having a mechanism that factors out system change notifications is very
> important, I also think that the current version is not quite ideal for
> several reasons. For example, I have a feeling that having so many
> different event classes is not always ideal because certain events 
> often
> occur together and are related. (E.g., when a method is changed and
> compiled in a n ew category as well).
>
> In this sense, it is important to view Roel's design not as a totally
> final/perfect solution, but more as the  first attempt to do something
> better.
>
> Cheers,
> Nathanael
>
>
>> -----Original Message-----
>> From: squeak-dev-bounces at lists.squeakfoundation.org
>> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On
>> Behalf Of stéphane ducasse
>> Sent: Sonntag, 1. Mai 2005 17:18
>> To: The general-purpose Squeak developers list
>> Subject: Re: Confused about SystemChangeNotification
>>
>>
>> I asked nathanael to reply since he refactored roel's code.
>>
>> Stef
>>
>>> Hi -
>>>
>>> I am running into ever more trouble with
>> SystemChangeNotification. Can
>>> somebody give me a brief rundown on how it is supposed to work? Any
>>> tests associated with it to document boundary cases? Here are two
>>> rather obscure issues that I am just running into:
>>>
>>> a) When I compile a method in another category, no
>> recategorized event
>>> is generated. Why? It is impossible to find out where a
>> method "came
>>> from" when using the modified event. This is easy to fix since the
>>> code in ClassDescription>>addAndClassifySelector: selector
>> withMethod:
>>> compiledMethod inProtocol: category notifying: requestor explicitly
>>> suppresses this notification. But the question remains -
>> why do it in
>>> the first place?
>>>
>>> b) When renaming a class the renamed event refers to the class under
>>> the old name. In other words, rather than getting our hands on the
>>> class under the name by which it is known in the
>> environment we get it
>>> under the old name which no longer exists in the environment. Why?
>>> This is totally inconsistent - it exposes the fact that the
>> invariant
>>> "aClass == aClass environment at: aClass name" is
>> temporarily broken.
>>> Why?
>>>
>>> If there are any good reasons for the strange behavior above I'd
>>> really like to know why it behaves that way.
>>>
>>> Cheers,
>>>   - Andreas
>>>
>>
>>
>>
>
>
>
Roel Wuyts                                                              
   DeComp
roel.wuyts at ulb.ac.be                               Université Libre de 
Bruxelles
http://homepages.ulb.ac.be/~rowuyts/                                    
Belgique
Vice-President of the European Smalltalk Users Group: www.esug.org




More information about the Squeak-dev mailing list