The notion of "what is a program" has remained almost unchanged since 
ST-76. Even the default browser is the one that was created by Larry Tesler 
at that time. Those of us who are satisfied with the original system 
architecture can make some surface refactorings and be happy.

I am not happy because I find I spend an inordinate amount of time reading 
code without really understanding it. I can read almost every statement, 
but cannot envision what the objects are and do at run time. (And this 
applies to code I wrote a year ago.) I need to change the very notion of a 
program to get through the barrier to the run time objects. This means 
introducing higher level, object oriented notions to give me leverage and 
to hide some of the most obfuscating facilities.

I don't believe I am alone in this. The current work on namespaces is one 
initiative,  traits could be another part of a future solution.

Cheers
--Trygve

At 27.11.2004 23:39, Colin wrote:

>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
>
>


-- 

Trygve Reenskaug      mailto: trygver <at> ifi.uio.no
Morgedalsvn. 5A       http://heim.ifi.uio.no/~trygver
N-0378 Oslo           Tel: (+47) 22 49 57 27
Norway