Feedback on SystemChangeNotification

Alexandre Bergel bergel at iam.unibe.ch
Tue Jul 1 14:13:11 UTC 2003


Hello Roel!

First I would like to apology for not having answered to your proposition sooner. I am actively working on the classboxes, so I spend much less time to read the squeak mailing list than before.

Before I expose my feeling, I would like to say I have nearly never work with a registration/notification/whatever mechanism, so perhaps I am missing some critical points. First I explain how I could use it for with classboxes, and then I expose some comments about the model.

1-Do I need High Level Event?
----------------------------
----------------------------
Probably the high level event will be needed for my work. Basically, the system event mechanism will filter for me only the event I need (e.g., I do not want to be bothered by a method recompilation if I manage some coarse grain such as classbox, and I only care about dependancies between classboxes).

Let me provide two examples arguments:
-a new class is added in a classbox
-a new method is added in a class, contained in a classbox

1.1-New Class is Added in a Classbox
------------------------------------
I would write something like:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
SystemChangeNotifier>>newClassNamed: aClassname inClassbox: aClassboxName
  (SystemAddedEvent item: aClassName kind: #class parent: aClassboxName kind: #classbox) trigger: eventSource
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Let take the case where a classbox CX1 imports a classbox CX2 (i.e., CX1 imports all the classes which are under the scope of CX2). Such event would be useful to check some conflicts (if a class named C is defined in CX1, a conflict appears if a class named C is added/created in CX2--In the V1 of Classboxes, there is no aliasing).
In this case, I would have these events:
---
|basic--added
|item: #B kind: #class
|parent: #CX1 kind: #classbox
---

and the high level events would be (ordered as emit order):
---
|high-changed
|item: #B kind: #class
---

---
|high-changed
|item: #CX1 kind: #classbox
---

1.2-New Method Added in a Class, Contained in a Classbox
--------------------------------------------------------
Note for this example I rise an issue not pointed in your implementation, about parameters passed to event.

The interface should provide me something like:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
SystemChangeNotifier>>newMethodNamed: aMethodName forClass: aClassName inClassbox: aClassboxName
  ...
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
For any new method, the low level event would be:
---
|basic-added
|item: aMethodName kind: #method
|args: #(#(aClassboxName #classbox))
|parent: aClassName kind: #classbox
---

and the high level events would be (still ordered as emit-order):
---
|high-changed
|item: aClassName kind: #class
|args: #(#(aMethodName #method)
---

---
|high-modified
|item: aClassboxName kind: #classbox
---

In the both example, I would really prefer to be notified only by the high level event, and not on the low one. 

2-Some comments:
---------------
---------------
-Everything expressed with low events cannot be expressed with high events. In your first example in the unit-test, a class is added in a category: the high events does not provide any clue (except by refering to the low event (original)) if the class is added or removed. I think it is not an important issue. If anyone need to be notified by such "low level" event, it just have to register to them.
-Have you thought about passing arguments?
-The "changed event" is emitted first, followed by the "modified" one. Why did you choose this order? According to my examples, it seems more natural to the opposite order (i.e., first I would like to get notified when a classbox is modified, and then look at the class changed).
-the precedent point make me think about "how to design the client". Right now, the client does not have any control on how to get notified. Do you think we should provide a queuing mechanism? I am not saying we should generalize that, but perhaps to provide some easy-to-use mechanism.
-In the mailing list, I have seen there were some discussion about having events synchronized or not. From my experience (I get with mobile agents when I was working at INRIA), having asynchronized events is difficult to handle... And right now I do not see any convincing example for having them asynch.
-How do you handle changing a superclass?

I really like what you have done.

Cheers,
Alexandre



On Tue, Jul 01, 2003 at 08:45:53AM +0200, Roel Wuyts wrote:
> Hi guys,
> 
> can you have a look at the stuff I sent around yesterday? If things are 
> not clear, then just write a mail or phone me on the following number 
> ++32 15 51 47 66. Or on my Swiss phone, but then it gets more expensive 
> for me :-)
> 
> What I really want to know is whether you can use the 'higherLevel' 
> events or not. The idea is that clients can register to receive only 
> basic events (a class is removed, a method is added), or that they can 
> receive 'higher-level' events that are sent by the system after the 
> basic event (for example, when a method is removed from a class, I also 
> sent a 'class modification' higher level event). I think that this can 
> be useful, but tell me...
> 
> PS: Note that I am at the hospital between 1:30 and 6 today, so I'll 
> not be available then.
> 
> 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

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.iam.unibe.ch/~bergel
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



More information about the Squeak-dev mailing list