=?ISO-8859-1?Q?st=E9phane_ducasse?= <ducasse(a)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.