Feedback on SystemChangeNotification

Roel Wuyts wuyts at iam.unibe.ch
Wed Jul 2 19:48:27 UTC 2003


:-)

I will post a new code blurb in a moment, so better wait until that one.
But I did not follow the idea I posted there (since I fully agree with 
you, and they are too different). So I created different, specific 
events for them. You'll see this in a short moment :-)

On Wednesday, Jul 2, 2003, at 18:58 Europe/Zurich, Daniel Vainsencher 
wrote:

> I bring to your attention that change of superclass and change of
> categorization are very very different events, semantically. I am sure
> you're well aware of this, but the user of your framework may be
> confused by this. So I'd avoid sharing an event type, to make this
> distinction very clear.
>
> How about SystemInheritanceChange and SystemRecategorizationChange? 
> ugly
> as a used cigarette ;-), but semantically clear.
>
> I've still to look at your code, but I will as soon as I'm done with my
> duties for the 7th. Deadlines have their benefits... :-)
>
> Daniel
>
> Roel Wuyts <wuyts at iam.unibe.ch> wrote:
>> 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
>
>
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