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