> No, it's really not.  It doesn't introduce  any dependencies.  It's a 
> completely separate method that isn't sent by any of the "core" 
> methods of Object.  There's no reason to remove it.

Sorry it does. I know what you mean but to be correct any class 
reference to another class creates a dependency.
Now you are right we have tool to manage them and I forgot to mention 
that.

> If you're concerned about marking it as part of the Browser package 
> rather than the Kernel package, we have mechanism for doing that - put 
> it in a method category labelled '*tools-browser'.  But please, 
> please, don't confuse which class a method is on with which package 
> it's in.  You know better than that, Stef:  I expect that kind of 
> argument from newbies complaining about #isMorph, not from a seasoned 
> Smalltalker.

I know I simply forgot ;?. Wonder why. I know I never really used 
packageInfo because I was waiting for dependencies between
MC package. May be I'm spoiled to develop in VW?

> And "we don't have a package system in the base" is both incorrect 
> (PackageInfo is meant for exactly this purpose) and a poor excuse (if 
> we start destroying the design of the system because we don't have a 
> package system now, how will we fix it once we do?).
>
> I hugely appreciate the work that KCP does, but removing methods like 
> that is counter productive.  Let's put it back, properly categorized, 
> and if there are any similar removals that KCP has done we need to 
> know about them so we can reverse them too.

I checked here is the answer: So this was before PackageInfo was 
introduced I guess.

'From Squeak3.4 of 1 March 2003 [latest update: #5170] on 28 March 2003 
at 4:31:22 pm'!
"Change Set:		KCP-0019-rmBrowseInBehavior
Date:			28 March 2003
Author:			stephane ducasse, alexandre bergel, and nathanael schaerli

remove the method browse from Behavior. Note that the sender in 
HTMLInput is calling the method browse from FileInput, so there is no 
problem "!

Behavior removeSelector: #browse!

Then doug is right for me. The fact that I could reply that reveals 
that the status of PackageInfo is not yet in our culture.

Related to that I have problem to know what is the status: packageInfo, 
MCInstaller, SarInstaller....
Can I for example load a sar file containing MC package in 3.7. really 
I do not know. I do not have the time
to learn. This is not that I do not want. I'm just trying to do too 
much and I'm losing time.

Then you know that I would like to have ***more*** than packageInfo. 
Just for the track, I'm trying to convert my code to MC and 
SqueakSource. My gut feeling tells me that relying on naming 
conventions does not scale. I'm evaluating how to do it and at then end 
it will work but still I'm really curious to know why I have this small 
voice inside.
So may be I want to go too fast but why can we replace class categories 
by first class packages?

This is fun to see that in the realm of everything is an object we are 
still relying on idiot string and dummy folder
without any behavior.

Stef