There's a heuristic that says incremental wins are good, but there are 
cases that don't apply. ("The world is better off without Saddam Hussein 
in power, no?") How do we know that this isn't leading the kind of "half 
a loaf" (non-)solution that I tend to worry about?

Guy Steele once told me that the first thing he tries to get right about 
a language is the namespace. "Get that wrong and you'll never recover."

I like Andreas' way of comparing what the proposal does to the cost of 
programmer changes. Determining whether his analysis is correct depends, 
I think, on what the proposal is actually doing, no?  I think it's 
possible to implement it in such a way that changes scale appropriately, 
but it is not yet clear to me that the code actually does things that way.
-Howard

Hernan Tylim wrote:
> +1
> 
> I like Goran solution. Its true that only  fixes the "prefix" problem  
> and not the "namespace" problem, as Andreas pointed out. But to me that 
> is not a bad thing. its one step further to make Squeak a little more 
> comfortable.
> 
> Regards,
> Hernán
> 
> On 29 Nov 2006 15:59:41 +0100, *Lex Spoon* <lex at cc.gatech.edu 
> <mailto:lex at cc.gatech.edu>> wrote:
> 
>     Andreas Raab <andreas.raab at gmx.de <mailto:andreas.raab at gmx.de>> writes:
>      > Generally speaking, I'm -1 on the proposal, mostly because what the
>      > proposal doesn't achieve is to make a real step towards enabling
>      > scalability of development (which to me is really what we're
>      > after). That's because the *author* of some code still needs to find
>      > unique names (prefixes) that do not conflict with the rest of the
>      > world and that a "change of prefix" becomes very, very expensive
>      > because it's literally like renaming all of the classes at once (and
>      > consequently breaking all of the code that uses any name from that
>      > "prefix space").
> 
>     It's a good observation.  Nonetheless, a hierarchical global namespace
>     seems a good step forward over a flat global namespace.  I do not know
>     about *this* system, but in general I would love if global variables
>     and classes had long hierarchical names.  Using the existing class
>     categories would seem great for that.
> 
>     Right now, responsible programmers already fake a hierarchical
>     namespace by putting prefixes in front of all their global names.  At
>     the very least, it would be nice to support this practice in the
>     programming language.  Ideally, you can even use long names
>     ("Monticello") instead of short prefixes ("MC") and thus greatly
>     reduce the chance of conflicts.
> 
>     In practice, I bet it's not so hard to pick prefixes that are unique
>     in the contexts the package will be used in.  Most of the time, you
>     can just use the name of the project, which you have surely already
>     gone to some efforts to try and make unique.  If nothing else, all the
>     open-source projects would benefit!
> 
> 
>     Finally, keep in mind what the great naming systems you describe for
>     the future would look like.  They will probably still have path-based
>     identifiers!  The only difference from hierarchical names would likely
>     be that the path can start from somewhere other than a single global
>     root.  Thus, a flexible hierarchical-naming system would seem like a
>     good basis for the kind of naming system you are thinking about.  (In
>     particular, you would want Foo::Bar to really mean "Bar" within
>     "Foo"....)
> 
> 
> 
>     -Lex
> 
> 
> 
> 
> 
> -- 
> Saludos,
> Hernán
> 
> 
> ------------------------------------------------------------------------
> 
> 

-- 
Howard Stearns
University of Wisconsin - Madison
Division of Information Technology
mailto:hstearns at wisc.edu
jabber:hstearns at wiscchat.wisc.edu
voice:+1-608-262-3724