On Nov 27, 2004, at 10:30 PM, Doug Way wrote:

> On Nov 26, 2004, at 4:27 AM, Trygve Reenskaug wrote:
>
>> Stef,
>> A bad idea, IMO. A namespace should be a place for mapping names to 
>> objects, the behavior kind is a special case.
>
> This argument seems unconvincing to me.  The behavior kind may be a 
> special case, but in practice it is probably 99%+ of the actual uses 
> in Squeak.  This creates the expectation that an unfamiliar 
> capitalized name in some code is going to be a class.  (Not counting 
> class variables.)
>
> You get a significant benefit in readability/clarity/uniformity of 
> code if you know that all of these capitalized names are classes, with 
> "Smalltalk" as the only exception.
>
> And of course you still have global variables in a sense if you still 
> allow access through the Smalltalk global dictionary. (e.g. "Smalltalk 
> transcript")  They just become a teeny bit less convenient, which 
> seems appropriate to me... the less common usage should be more 
> verbose, and the more common usage should be less verbose.

I have to agree with Trygve here.

A namespace is a mapping from names to objects. If we find we need to 
do a lot of special casing around certain of those objects which happen 
to be classes, it's a sign we don't have the abstractions of the system 
very well separated. It may well make sense to have a mapping of names 
to classes, but if so, it's a ClassDictionary, not a Namespace, and we 
need to understand what that means for our design.

It seems to me that we need to clarify the lexical scoping rules for 
Squeak, particularly as they relate to environments. If we do that, the 
abstractions we need will be obvious, and then it's just a matter of 
getting the compiler to use them correctly.

Regarding globals vs class names, there's no reason they have to be in 
the same namespace. Each environment could have a class dictionary and 
a global dictionary; as long as we search them in a consistent order, 
all is well. On the other hand, I don't see how having only one global 
is any better than having a few of them; you still have to special case 
it or move it to another namespace.

Finally, consider this: removing globals is a significant change to the 
semantics of Smalltalk. If we decide to do that, fine, but it should be 
because we think it's an improvement to the language, not because it's 
marginally easier to implement.

Colin