Hi,

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

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