> For example, how often do you move a method 
> from one package to another (this is the first item in the message list 
> menu)? Rarely, if ever. 

Actually, you will need to do it if you want to extend a class with a method. Let's assume you want to add a method asUrl on String. You first go to the package Collections, in the subcategory Text, click on String, and then add your method asUrl. However this method belongs to the package Collection. You have to move it if you want it belongs to your package. 

By the way, I do not really like this approach too. Perhaps setting the package on of your application as a 'reference' would help. Then all the methods added outside your 'reference' package are extensions. I do not know yet. Feedbacks from intensive users of MC would help here...

> It is dangerous to overload the more common 
> actions with lots of esoteric things that are rarely used. 

I think it depends. Having one tool for editing and refactoring code is quite confortable. I do not know if having package refactoring tools available on the standard code browser is a good thing or not. I feel it worths trying. The refactoring browser follows this idea. If Smalltalk had packages, RB would probably have some refactoring tool for it.

> So what I'm trying to say here is you walking a very fine line here and 
> you need to be careful not to make that new browser so package-centric 
> that it is no longer as useful as other browsers for general-purpose 
> programming. This should be an interesting exercise and probably needs 
> lots of feedback from real users (both novice and expert).

I fully agree. I am absolutely not saying that my current approach is perfect. However, I think there are ways to edit/manage packages other than what PackageInfo/MCPackage offer.

Alexandre

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.iam.unibe.ch/~bergel
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.