Ok, I'll wait to see some code, and give you some more well grounded
comments.

Just hope that the proliferation of needed events don't get you bogged
in constant changes to the Kernel/UI where these things are generated...

Daniel

Roel Wuyts <wuyts at iam.unibe.ch> wrote:
> No problem, we are in sync (this is what I meant with my reply - it 
> depends on whether anybody needs to know about this. Because if you do, 
> and it is not there, then things get ugly :-(  ).
> 
> And no problems of it stopping me: I am happily implementing some first 
> things :-) I'll send a first code blurb as soon as possible (just to 
> give some ideas).
> 
> Bring it  on :-) :-)
> 
> On Sunday, Jun 29, 2003, at 14:55 Europe/Zurich, Daniel Vainsencher 
> wrote:
> 
> > Roel Wuyts <wuyts at iam.unibe.ch> wrote:
> >> On Saturday, Jun 28, 2003, at 22:35 Europe/Zurich, Daniel Vainsencher
> >> wrote:
> >>> - What does a method/class recategorization trigger?
> >>
> >> Good question, since it is essentially a 'move'. So I guess it should
> >> do a removal/addition pair. Or maybe a separate event. It depends on
> >> whether anyone needs to know specifically about recategorization.
> >
> > Just some things to think about -
> > If you consider methods to be merely behavior of a class, then method
> > recategorization shouldn't bring up any events at all, because behavior
> > hasn't changed. This is correct, because it is a view that might be
> > useful for some applications (concerned with behavior) but it isn't
> > complete, because other applications are interested in structure
> > (MudPie), which does change. So maybe having events for both
> > complementary perspectives is the only way to serve all those needs.
> >
> > While most applications could be written successful to deal with
> > recategorization encoded as remove/add, consider that this loses
> > information, and then applications might need to start interpreting the
> > event stream to know what really happened (was that really removed, and
> > I need to run that classes tests again, or was it merely moved?). So it
> > might be better to consider a richer abstraction of possible events.
> >
> > Note that I don't want these meandering thoughts to stop you from
> > starting to implement something coherent and simple, I just thought I'd
> > complicate things a little before triage begins...
> >
> > Daniel
> >
> >
> 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