> Load Package A which defines method X.
> Load Package B which redefines (and "takes ownership of") X.
> Modify some other method in Package A and save a new version of the 
> package.
>
> Since Package B has taken over X, this new version of Package A will 
> not contain it.  If you now load Package A into a new image without 
> Package B, X will not be there at all.

Yes I missed this one.
:) I should try that with VW. (I'm trying to concentrate with kids 
around .... not easy!)

>
> You could (if you were aware of the problem) get around this by 
> unloading Package B, saving Package A, reloading Package B, but that's 
> quite a hassle.
>
> You could also make PI smarter so that it would peek back into the 
> versions of a method looking for overrides when you save (as MC does 
> on unload), and still find such shadowed methods, but it would be way 
> too slow.

I have the impression that you do not have to  always save A>X. because 
may be you want not A>X anymore or may be
you want the new B>X now to be in A>X. My impression is that there is 
no magic and that the user should be aware
in which packages the methods are and get warned what to save and 
where. So this makes the browser more complex and also development 
because we have to take care of that.

> I think the only way to properly solve this is to have an object that 
> explicitly tracks which methods are in which package, updated by 
> something like Roel's notifications.
By the way roel is swamped by C lecture on algorithms and joseph said 
that he wants to improve the notification design but after that we 
should really get some users (alex is using that daily) but having guys 
could be good for feedback. Ask alex if you need a version.

stef