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
>
>
>