Hi florin

I really like the quality of your discussion with colin. Thanks for 
that.

> Here, I am not so sure.
> As I see it, there are two reasons for having overrides. One is to 
> offer an automatic resolution for accidental collisions, and as a way 
> to guarantee that your package _can_ be loaded (without manual 
> modifications) in its intended state, mentioned above.
> The other one, that I mentioned in my reply to Dan's message, is for 
> intentional overrides of something that is known to exist and to be 
> used in the pre-existing image (either because it is part of the base 
> image, or because it is part of another, required package). Sometimes 
> you do need hooks in other packages or in the base image, to attach 
> yourself to a pre-existing state, and they are not general enough to 
> justify a "fix" in the base image. Since they are specific to your 
> package, they should belong as organizational structure to your 
> package as well, just like normal (non-conflicting) extensions would. 
> And it's not just about methods. As an example, your module wants to 
> add some state to processes, so it needs an additional instvar in 
> class Process. Shouldn't this change to a pre-existing class 
> definition be contained in your module, be loaded with it, and be 
> unloaded when the module is unloaded? This is clearly not an 
> accidental collision, but it does not make sense by itself in the 
> module originally defining class Process.

I agree with you.
In Classboxes (again I'm not saying that this is the solution) we took 
the idea that overrides, extensions, state extensions
were local to the package doing them. I would really appreciate if you 
could comment on our papers (on the list or privately). I'm not sure 
that always having the semantics we gave to extensions is the one we 
want but at least we have a consistent world.

Stef