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@lists.squeakfoundation.org [mailto:squeak-dev-bounces@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