my point was simply that we have 12 global variables in the system and that we all know that global variables is not a so good ideas so I was thinking that this would be nice to remove them. There is a lot of clunky logic in SystemDictionary just to deal with these globals isBehavior sent to all the binding values to make sure that we get only classes (of course we could have two dictionaries one for classes and one for variables we did that in a previous version but we would have to test also a lot more to make sure that we can't have a variable and a class with the same names if we want to keep the current shared namespace semantics of smalltalk). Now the idea of having classVariable in Object could be one way to do that. But you argument about typing less is not really sexy since this is true that is is shorter to type Smalltalk than Namespace smalltalk but you block the fact that we can have multiples ones. So everything is a question of cost and World current vs World to get rid of a not so good concept would be a deal I would sign for today. Except if there are other problems such as: it is easier for the VM to access to this globals than to have a msg send (which would be solve via Object classVariables)
Now about the future of Squeak I agree with you I prefer something malleable and simple. Because simplicity is also beauty for me. I'm just thinking that sometimes it may be easier to simply hack something in our corner without any idea of sharing it because we could go much faster and further and with much more fun (but this is my dark face that is talking of course). Our current goal is to make sure that we or other can invent the future (this is why we clean the kernel not for fun or masochism).
Stef
On 28 nov. 04, at 16:54, lex@cc.gatech.edu wrote:
It would be good to use class variables of Object instead of globals, just so that we can have one fewer kind of variable. The global variables would then be the class variables of Object. That's a pretty nice way to go: it simplifies the language while having no practical cost that I can think of.
It would also be possible to invent new classes and stuff the current globals into them. So it would be "World current" instead of "World". But that actually seems to be a step backwards. If I want the current world--an important concept for Morphic programmers--why should it require more than one word to name what I want? Maybe you are thinking that when I write "World", the semantics should be other than a simple variable lookup like right now? Well, if that ever happens, then let's revisit the idea. Right now, variables are the only way in Squeak to get one-word names for things.
I do not understand the multiple types issue that you bring up. I agree with Trygve that it is nice to have a *general purpose* mechanism for mapping names to the *objects* they denote. It is hard to predict what individual words we would like to be globally acceptible in the future, but notice that we already have some (World, Smalltalk, Sensor, Display) which do not denote classes and which have been proven convenient over the years. I don't want *any* of these to require multiple words to specify, and so I am not convinced that only classes should be named at the global scope. You mention testing for whether something is a class or not, but when should this happen? For one, there are already plenty of methods for navigating the class hierarchy; for another, they can just as well be implemented with code like "ProtoObject withAllSubclasses" instead of by rooting around in the global variables.
So in short, reimplementing globals as class variables of Object: good. Replacing all globals with a two-word designation: bad. Yes, we want the language design to be pretty and concise, but we should also strive for things *written* in the language to be pretty and concise.
Lex