About removing global variables

Richard A. O'Keefe ok at cs.otago.ac.nz
Thu Dec 2 03:16:04 UTC 2004


=?ISO-8859-1?Q?st=E9phane_ducasse?= <ducasse at iam.unibe.ch> wrote:
	by global I meant variable holding something else than a class and 
	stored in Smalltalk.
	
That is not what 'global' normally means.

	SystemOrganization is one that is badly accessed and should not since 
	it should be accessed via Smalltalk organization.
	
There are a number of odd things about SystemOrganization.
One is that its class comment says
                v
    My instanceS provide an organization for the classes in the system...
                ^
and yet there is only one instance, and as far as I can tell, only ever
meant to be one instance.  If, instead of being an(the) instance of
SystemOrganizer, it were a subclass of Object holding an(the) instance
of SystemOrganizer as a class variable and with all the methods of
SystemOrganizer mirrored as class methods of SystemOrganization, it
would, for all practical purposes, be indistinguishable from what it is
now, yet by the definition of 'global variable' above would no longer be
a 'global variable'.

    I can't think of anything I'd do with SystemOrganization that I wouldn't
normally do through the UI instead, so it's no skin off my nose if it's put
in Smalltalk.  I do wonder how one decides where to put it, though.  It has
never been clear to me just how much must be shared between projects and
how much can be different.  Can different projects have different
organisations, and if not, why not?

	> 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 

You seem to have completely missed my point.
My point is that Squeak ALREADY HAS the required concept
(global named read-only binding).
I am not proposing a new concept, not in the least.
My proposal is simply that we use an *EXISTING* implemented
concept in Squeak to enforce what is already the intended use
of a number of globals (like 'Smalltalk' itself).



More information about the Squeak-dev mailing list