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