> That is an important consideration.  If it is truly 
> incremental, then that is a really nice property.
> 
> However, is it really?  How will we migrate forward to a 
> hierarchical system where Array is at 
> Collections::Core::Array instead of at Collections::Array ?  
> There will already be code everywhere using Collections::Array .

He's not saying everything in the image needs to be converted to this, all
the core classes can stay as they are now, global.  The :: will mostly
enable *new* code or code you choose to rename to use browser aware prefixes
that can be hidden.

> This all sounds very hasty to me.  Instead of endlessly 
> evaluating a quick and dirty scheme, 

People have been trying to get some form on namespaces in Squeak for several
years now.  Gorans proposal is quite old, how exactly is that hasty?

> how about the 
> enthusiasts get together and make a system where:
> 
>   1. Baby code in a starter image can mostly ignore namespaces.
>   2. A full hierarchy is available, not just one level.
>   3. Import lists are localized.
>   4. The source code does not need automatic rewriting
>      in order to look nice.
> 
> This is a doable list of properties, and I believe it could 
> be solved faster than trying to convince everybody to use 
> something incomplete.
> 
> For bonus points, don't forget to check on the existing 
> systems like GST's and VisualWork's, and don't forget to poll 
> the major producers of Squeak code about what they want.
> 
> Lex

Seriously, if we can't even agree to formalize some minimal tool support for
the *existing practice* of prefixing, I can't see that anything else will
ever get done.  

How many times does the attempt have to fail before everyone sees that these
big sweeping hierarchtical/import solutions won't be accepted? Are
namespaces in Squeak are just doomed to endless debate resulting in doing
nothing over and over again and while we're all stuck with manual prefixes
or non-standard add in packages forever?

Ramon Leon
http://onsmalltalk.com