About removing global variables

Richard A. O'Keefe ok at cs.otago.ac.nz
Wed Dec 1 01:14:57 UTC 2004


=?ISO-8859-1?Q?st=E9phane_ducasse?= <ducasse at iam.unibe.ch> wrote:
	my point was simply that we have 12 global variables in the system

It depends on what you mean by 'global variable'.
In Squeak 3.6-5429-full (so missing some cleanup),
there are in fact 1809 global variables.

Just because the value of a global variable happens to be a Class
doesn't make that variable any less global or any less variable.

I can't do this:

    t := False. False := True. True := t.

In Ambrai Smalltalk, True and False are "read only variables".
I could do it in Squeak 2.8  In Squeak 3.2 and later, I can't do it,
because "False := True" is automagically converted to "False value:
True", which confuses the heck out of me.  (It just shows you how often
I _want_ to do this; I hadn't noticed this change.  The change itself
rather horrifies me.  I would rather have an unwelcome operation blocked
at the first step, being told "don't do <THAT>", rather than converted to
something else which just happens to fail "<SOMETHING ELSE> didn't work".)
If I go the "Smalltalk at: #False put: True" route, I am given the vastly
superior error message 'Cannot store into read-only bindings'.

So it would appear that class names are not variables.  But just because
I can't modify them directly doesn't mean they aren't variables.  It just
means I have to use

    t := False.
    [Smalltalk at: #False put: True]
      on: AttemptToWriteReadOnlyGlobal do: [:ex | ex resume: true].
    [Smalltalk at: #True  put: t]
      on: AttemptToWriteReadOnlyGlobal do: [:ex | ex resume: true].

Yup.  They're variables, I just varied 'em.  Nearly 2000 global variables.

	and that we all know that global variables is not a so good ideas

We know global *variables* are not the best (but arguably not as bad as
a compiler turning one kind of construction into a radically different
kind without warning, like := turning into #value:).  However, just how
"variable" are these variables?  There is nothing wrong with global
named CONSTANTS after all.

In Squeak 3.6-5429-full,
    Smalltalk keys reject: [:each | (Smalltalk at: each) isKindOf: Class]
returns
s   ActiveEvent
s   ActiveHand
s   ActiveWorld
-   Display
-   ImageImports		(lazy-initialised; why global?)
-   Processor
-   References
s   ScheduledControllers	(switched when switching projects)
?   ScriptingSystem		(either - or s)
-   Sensor
-   Smalltalk
-   SourceFiles			(doesn't really need to be global)
-   SystemOrganization
-   TextConstants
s   Transcript			(switched when switching projects)
-   Undeclared
-   WonderlandConstants
s   World

Key:
    Varied by user:   u.
    Varied by system: s (as a normal sort of thing)
    Not varied:       - (after possibly lazy initialisation)
    I have no idea:   ?

There are mistakes in this list, no doubt, and it's for a 3.6, not
a 3.8, system, so it's obsolete anyway.  Apparently the list is shorter now.

The really really important thing is that from a user perspective

    I SEE NO GLOBAL VARIABLES HERE.

That is, I see nothing that *I* want to modify.  Each of them is, as far
as I am concerned, a globally visible named object.  If each of these things
were made a read only binding just like class names, none of my code would
notice and very little system code would notice either.

	so I was thinking that this would be nice to remove them. 

This is to remove the wrong aspect.  It's not the globality that is
a problem.  On the contrary, you *want* things like Smalltalk and
Sensor and TextConstants to be global.  It's the (accidental)
*variability* that is a problem.  So take *that* away.  Squeak already
supports global read-only bindings (with careful rebinding by system
code); so use that mechanism for these system globals as well.

Now, if we had 1800 global named constants (other than class names),
then "globality" _would_ be a problem, and we'd need to partition that
name space somehow.  But with just 12, let's focus on the right problem.
Having 12 globally visible named constants is _not_ a problem.




More information about the Squeak-dev mailing list