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 don't know... it just seems that it's probably worth getting rid of a language feature that is relatively little used and so easy to replace with other mechanisms. This ain't C++, after all. ;) ;) ;)
So Stef, you have my vote to proceed. :)
Although I admit I haven't thought deeply about how a real namespace mechanism (such as Goran's or something like classboxes) would affect all of this.
- Doug
In UML, a *component* is a model element that encapsulates other elements, its named parts. In BabyUML, a component is an object that encapsulates a number objects, its named parts. This component maps names to parts in a private namespace.
In general, I feel that we do not get the full benefit of object orientation by exclusively focusing on classes and class structures. This was a weakness of early UMLs, it is also a weakness of current Smalltalks.
So let namespaces bind names to objects in general. Your work on multiple workspaces opens vistas of different kinds of system modularization, their namespaces will contain many interesting objects the like of which are not found in the current Smalltalk dictionary.
Cheers --Trygve
At 25.11.2004 16:43, you wrote:
Hi
I wanted to get feedback about the idea of removing global variables in Smalltalk. The fact that system dictionary or a namespace can contain variable ie (a binding to something else than a class) makes the code quite ugly since we have to always test if this is a class or not.
I think that we could easily remove the possibility to have global variable and move the ones we have into classVariable of Smalltalk or appropriate classes. This would lead to a more modular system.
Smalltalk keysAndValuesDo: [:k :v | v isBehavior ifFalse: [Transcript show: k ; cr]]
ImageImports Display ScheduledControllers ScriptingSystem Smalltalk CustomEventsRegistry World SystemOrganization References ActiveHand Transcript Undeclared SourceFiles Processor ActiveWorld TextConstants Sensor ActiveEvent
Now we would have to type Smalltalk transcript instead of Transcript.
Any thoughts.
Stef
PS: Backward compatibility is not a reason since we are about inventing the future not the past
--
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