Andreas Raab wrote:

>Check me on this - if I understand PackageInfo correctly then it determines
>which package a method belongs to by looking at the category. Since a method
>can only be in one category at any given time it is impossible to have it in
>two packages (if we use PI that is). So if you modify a method you've got
>two choices - either leave it in the one it was in or move it into one of
>yours.
>
>In case a) you essentially "patch" the method inplace and it still belongs
>to where it was originally. In case b) you take ownership of it. I won't
>comment on how useful either one is but it seems to me that we really can't
>have methods in multiple packages.
>

Yes.  The only problem (with PI) occurs when you do this:

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.

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