Hi Alexandre -

Some comments. First off, it would be useful if the web site could say 
more about the motivation behind your approach. The description of the 
current situation seems like nit-picking to me - it would be fairly 
straightforward to add support for PI conventions to the browsers, or 
making moving methods or renaming packages one-click exercises (if the 
issues you list would really bother me -which they don't- and I expect 
the same is true for many other MC users). But clearly, this is not 
enough to motivate a new package system so some information on why you 
feel this is necessary would be nice.

The issue that bothers me most about what I've seen so far from your 
approach is your idea of "making the naming convention irrelevant". 
While I agree that the category-prefix convention for classes may not be 
the best (though it is hard to beat in terms of convenience), the naming 
convention for extensions serves far more than just the need of 
classifying some method as belonging to a particular package. It is that 
extra information that is crucially lacking from your approach as far as 
I can see. Example for such information include:

* Which packages have modified this class? With the extensive use of 
Monticello in Tweak it has turned out that classes with many extensions 
often need redesign - the extensions are a sign that it is used in a 
different way from which it was originally designed and that the new use
should be factored into the design.

* Is method #foo an extension method? This is critical to know because 
one might accidentally use a pet method of some other package (say, 
Collection>>gather: which is defined by package info) that will not be 
present in the long term.

Right now, the naming convention gives us straightforward answers to 
these questions but they seem very hard to derive from your current 
browser design. I think it would be useful if there were at least a way 
of showing pseudo-categories of some sort that make this information 
explicit.

Cheers,
   - Andreas

Alexandre Bergel wrote:
> Hello,
> 
> I have been working on a new package model for Squeak. The implementation comes with a browser based on OmniBrowser. This last version is quite usuable. I use it for all the squeak projects I have. The webpage (containing a screenshot) is http://kilana.unibe.ch/monticellopackagebrowser/
> 
> If you are interested in having a better package unit, or in modularization issues, then you can contribute by giving me feedbacks.
> 
> 
> 1-Description
> A new package system coming with a new package browser intended to substitute PackageInfo and the old package browser.
> 
> Once loaded, execute "Package bootstrap". This is necessary to built some packages from the classes present in the system.
> 
> One does not need to rely on naming convention such as "*mypackage" to define class extension for instance. Moreover, operation like renaming can be performed.
> More info on: http://kilana.unibe.ch/monticellopackagebrowser/
> 
> 2-What is new in the last version
> Some new features were added to version 28:
> -When a package is stored, the old monticello naming convensions are used. This means that you can manage your application with the MonticelloPackageBrowser without risking loosing track for people who does not use this new browser.
> -Faster rendering, especially for the class extension.
> -Better menu arrangement. 
> -Some bug are fixed (e.g., browsing metaclasses of extended classes, ...)
> 
> Cheers,
> Alexandre
>