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