About removing global variables

stéphane ducasse ducasse at iam.unibe.ch
Sun Nov 28 12:03:51 UTC 2004


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




More information about the Squeak-dev mailing list