Bert Freudenberg wrote:
> Actually, that is the beauty of the proposal. Colons are already allowed 
> unquoted in a symbol. #My::Class is valid right now. In this proposal, 
> the compiler knows *nothing* about namespaces. It just permits a colon 
> in a global identifier. It's the only syntax change.

Is that really true? I haven't looked at the code in a while but Goran 
used code that I had originally written and that code most certainly 
wasn't just permitting colons in a global identifier.  What it did do 
was introducing explicitly scoped variables and the result of Foo::Bar 
would depend on what is stored in Foo's scope under the name of #Bar and 
not on what is stored under Smalltalk at: #'Foo::Bar'. Of course, these 
two can be made the same by using the same association but that's still 
quite a bit different from just permitting colons in global names.

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

So basically you're trading the probability of conflicts (reduced due to 
the increased length in names) with the severity of conflicts (increased 
since changing the prefix is more expensive). It's an incremental 
approach that shifts tradeoffs but doesn't do anything to address the 
problem on a more fundamental basis (in all fairness, Goran never 
claimed it did but it's important in this discussion to understand what 
this proposal does and doesn't do to assess the impact of a change).

But since it's "only" an incremental shift in tradeoffs I wonder if a 
language change (with significant costs for compatibility) is really 
justified. It seems to me that the practical gain is fairly minor and 
there is little motivation that I can see for anyone with a "serious" 
project to adopt this solution given that it will neither be portable 
nor backward-compatible. Put on top that the proposal deliberately 
doesn't take a stand on any general modularity issues (visibility, 
dependencies), then what exactly does one gain?

To me the basic question here is: Is the prefix pattern so pervasive 
(and so problematic) that it deserves a special syntactic 
representation? Without taking a stab at the "real" problem (scalability 
of development) my answer is: No. It's a clever hack but nothing that I 
would loose sleep over if it weren't there (and I won't loose sleep over 
it being there either but I'd like us to be clear about what we're 
trying to achieve with adopting it).

Cheers,
   - Andreas