I agree. Still having a notification telling you that you move an 
overriden method slip. because you may have
two packages that define the same methods but you did not realize it. 
you took them from a friend and just use them :)

Stef

>
> Just to clarify - it seemed to me that the entire discussion about 
> having
> methods in more than one package is moot at this point.
>
> Having said this, there is one thing I'd like to add though. Maybe 
> (just
> maybe!) having a method exclusively in one package isn't such a bad 
> thing
> after all. I mean think about it - how often would we want to have a 
> method
> in more than one package and for what reason? There are only two 
> situations
> I can see: a) You have a utility method that you want to use from 
> different
> places. The answer here might simply be: Tough luck - put it into a 
> separate
> package and have that package be a prerequisite. b) You want to patch 
> some
> existing method. Personally I consider this one of the most problematic
> issues with Smalltalk in general - patching methods is something where 
> you
> effectively change the semantics of the entire package.

entire system :)

> Clients can no
> longer rely on it working the way it's intended to be (if you hack it 
> all
> bets are off) so maybe you really should be forced to provide "proper 
> hooks"
> inside of that package. In which case having the method belong to the
> original package is really The Right Thing to do. And yes, that'll 
> cause you
> lots of headaches in how to manage a package you hacked. And again, 
> maybe
> that's not such a bad thing - maybe you should add a "proper hook" and 
> feed
> that back to the original package for integration.

if classbox would be faster :)

>
> Just some random thoughts. I always found the Voodoo going on in this 
> area
> way over my head ;-) Having a few simple, strict rules isn't the worst
> situation to be in as long as you have some guidance on how to solve 
> the
> common problems you may encounter.
>
> Cheers,
>   - Andreas
>
>> -----Original Message-----
>> From: squeak-dev-bounces at lists.squeakfoundation.org
>> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On
>> Behalf Of Avi Bryant
>> Sent: Monday, October 13, 2003 8:30 PM
>> To: The general-purpose Squeak developers list
>> Subject: Re: PackageInfo ... where?
>>
>>
>> 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.
>>
>>
>
>
>