Colin Putney wrote:
Hi Florin,
I think I understand what you're getting at now. You prefer the "last package loaded" strategy because it guarantees that at least one package will remain in exactly the intended state, and thus presumably work. Ok, fair enough. I think this argument is moot any way since:
- What's appropriate probably depends on the circumstances under which
we're running. If I as a developer am loading a handful of packages to continue development, I don't mind risking a little breakage. But that's probably not the case if we're deploying for end users.
Agreed
- The modules system shouldn't be dependent on any versioning tool, so
we may want overrides (or some other strategy for dealing with multiply-defined methods) as a fall-back for when the versioning system isn't present.
Agreed
- Given Dan's interest in security, we'll probably want some mechanism
for preventing such method collisions from occurring at all. Classboxes, Islands or E probably has some solution that is more elegant than either overrides or versioning.
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.
One other case where I regularly use overrides in VW is bug fixes. Even if I submit them and they will eventually get included in the distribution (some of them, after a loooooong time), where do they sit in the meantime? And what if they are performance optimizations, or other kinds of changes that would never be included in the base? What am I going to do if you won't like my changes to MC and will refuse to include them ? :)
Part of a "project" may mean reverting a method to an existing, older version, reverting a class to an older version, reverting a package to an older version. This happens quite frequently when developing a patch. What does it mean for these components' history that you re-version them?
In MC2, if a developer reverts to an older version, the history will show that. A new version will be created, with identical "content" to the old version, but with metadata showing the intermediate version as an ancestor.
Colin