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
> >
> 
> 
>