Göran Krampe wrote:
> Please realize that the "syntax change" you refer to is about allowing $:
> in *global references*. As both I and Ramon has made clear you can ALREADY
> create globals/classes with $: in their name (!).

No, you can not. You can create *symbols* with colons in it but that's 
something completely different. I can also create a class like here:

Object subclass: #'Some Random Class with

#!@

in it'
     instanceVariableNames: ''
     classVariableNames: ''
     poolDictionaries: ''
     category: 'Kernel-Tests'

Try it, it works. Does that mean that spaces, carriage returns and 
binary symbols must be supported in global references?

> Either *that* is a bug
> or the fact that you later *can't reference them by their name* in your
> code is a bug.

As the above example shows the bug is that the class name is not 
validated. And yes, that is quite obviously a bug (which is even 
somewhat funny since I did validate inst vars and class vars and pool 
vars and about everything I could think of in ClassBuilder - just not 
the class name itself)

>>> that could begin to fork the world into ::-dependent and ::-free code?
> 
> Hehe, we have tons of other ways of making code "forked" - like depending
> on Monticello or depending on Traits etc etc. As I have shown we are
> talking about 4 method mods and one added method. All in all it is (let me
> count)...
> 
> 12 added lines and 7 modified lines of code. This is all you would need
> AFAICT at this moment to have ::-code working, see:
> 
>     http://swiki.krampe.se/gohu/35
> 
> I bet we can make this work in all Squeaks released to date with minimal
> effort.

Let me repeat: Language design is not a zero-sum game. I don't care if 
the change is four or four hundred lines of code. I don't care if VW's 
namespaces suck or if Croquet uses positional arguments. In *this* 
discussion I care about whether a change like you are proposing is worth 
it based *exclusively* on its own merits.

And if you are jealous that Croquet is able to make decisions you have a 
simple alternative: Make up a fork that shows the error of everyone 
else's ways. As a matter of fact I would vastly prefer that because it 
would mean that there is some actual usage to look at and that I don't 
have to take you at face value with all of these (so far completely 
unsubstantiated) claims. The nice thing about forks is that you can look 
at them, try them out, and then, with 20/20 hindsight can say whether a 
change like it makes sense for Squeak in general or not. But I don't 
think even you have used your namespace solution anywhere. So what 
exactly are your claims based on?

Cheers,
   - Andreas