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

Alex is not really a good marketing person :). I do not like that web  
site either.

Our motivation is twofold
     -  have first class packages with all the meta-information we  
can get:
package comments, author,... So the changes are just turning PI into  
a real object with its own state.
Just having real objects in Smalltalk make sense to me because we  
could imagine that package could be "parcel" and could load bytecode  
and others kind of cool stuff. Alex's first try at providing byte- 
code loading for package was much faster (I do not remember if it was  
1000 faster because we got some stupid stuff in our way).
     - having a better browser for Package may be with tabs as in VW  
so that in one click
     we can see the views you mentioned (all the extension of a  
package, all the package a class belong to)

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

200% with you on that. The point is absolutely not to lose that!

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

Getting rid of the * is really not the main motivation, even if  
starting to have *extremelylongandannoyingnames is annoying.

The browser should give us that information (the same information as  
it does in VW) may be also using
bold, italic, we could reinforce such feedback. I agree with you that  
I should be able to see all the extensions made to one class or all  
the class extensions done in one package and navigate through them.

In addition the browser is backward compatible with MC format so when  
you save you get the *star and the rest.

Stef