Feedback on SystemChangeNotification

Roel Wuyts wuyts at iam.unibe.ch
Tue Jul 1 17:30:40 UTC 2003


Hi again Alex :-)

I was thinking some more on your last point:
	-How do you handle changing a superclass?

It made me think about Daniel's question from a while ago:
	- What does a method/class recategorization trigger

I think both can be accomodated by introducing a:
	SystemMovedEvent, indicating the kind of 'move': to another category, 
protocol or superclass.

But I am not quite happy with the name; any better ideas? I was 
thinking about a StructureChanged, but that does not quite express it 
either...

On Tuesday, Jul 1, 2003, at 16:13 Europe/Zurich, Alexandre Bergel wrote:

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



More information about the Squeak-dev mailing list