Richard

by global I meant variable holding something else than a class and 
stored in Smalltalk.

SystemOrganization is one that is badly accessed and should not since 
it should be accessed via Smalltalk organization.

> 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
same here see my current cleans.

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

it is your point of view.  An extra concept that does not seems to be 
needed
but I will digest what you wrote and don't be afraid we will not remove 
them now. :)