On Monday, October 13, 2003, at 02:10 PM, Andreas Raab wrote:

> Hi Guys,
>
>> Yes, I was proposing that we prevent overrides at load time,
>> but perhaps that's being too restrictive.  But how else would
>> you prevent a method from being in two packages if you allow
>> overrides?
>
> 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.

Yeah, I stopped thinking about how PackageInfo is actually 
implemented... currently it only allows methods to be in one package.  
I already mentioned your option a), and then there is option b), which 
is what PackageInfo typically does now.

I guess it's really just a matter of whether we want to leave the 
PackageInfo behavior as it is now (which is pretty simple, at least), 
or not allow any method overwrites/patches (which is what you are 
getting at in your second message, I think).  I don't really have a 
problem with going with the current PackageInfo behavior.

- Doug