Re: if not global -- then what?



On Sat, 20 Feb 2010 11:25:46 -0800, egasimus wrote:

Hi, newbie here. I've read on using the 'global' keyword being
discouraged; then what is the preferred way to have something, for
example a class containing program settings, accessible from everywhere,
in a program spanning multiple files?

Such a thing is no different from keeping many global settings. It's not
the global KEYWORD that is discouraged, but the over-use of global
variables itself.

See, for example:

http://c2.com/cgi/wiki?GlobalVariablesAreBad
http://weblogs.asp.net/wallen/archive/2003/05/08/6750.aspx


In a nutshell: shared variables introduce tight coupling between parts of
your code that should be independent. Whether they are truly global, or
passed around in a Settings object, makes little or no difference. In
both cases, the risks and problems are identical.

Let me give a fanciful example: suppose your refrigerator, oven and
shower all shared a single global temperature setting instead of having
three local temperature settings. This would be a recipe for disaster:
every operation to any of the three would need to carefully save the
current temperature setting, and there's the constant risk of scalding
showers, ruined foods, and undercooked meals.

Having three different global temperature settings helps a bit, but that
just expands the number of variables that everything has access too. Why
do the television and the garage door need access to any temperature
setting, let alone all three?

Python globals aren't as bad as in some other languages, because "global"
means global to a single module, not global to the entire program, but if
you create a Settings object and import it from module to module, you
break the encapsulation, *and* you then have the problem of needing to
make sure it is initialised properly.

http://archive.eiffel.com/doc/manuals/technology/bmarticles/joop/globals.html

Global constants also aren't as bad, because the coupling is weaker.
Unfortunately Python doesn't have constants, except by convention, so
there's always the risk that some badly-behaved function might decide to
redefine (say) math.pi to 3.15.

Unfortunately, you probably can't get rid of globals altogether, but the
tricks are (1) use as few of them as possible, and (2) make them local as
quickly as possible.

For example, you might have something like this:

default_header = "My special header" # A global

for option, argument in command_line:
if option == "--header":
default_header = argument

class Printer:
def print_page(self, text, header=None):
if header is None:
header = default_header
print header
print text


I would limit the scope of default_header so that it was local to the
printer class:


for option, argument in command_line:
if option == "--header":
Printer.default_header = argument

class Printer:
default_header = "My special header"

def print_page(self, text, header=None):
if header is None:
header = self.default_header
print header
print text

You might not be able to completely eliminate either globals, or a
Settings object, but you should be able to make it much, much smaller.

In practice, to make testing easier, I'd split the command line
processing into two steps: a function that reads and processes the
command line into a single local settings object, then a separate
function that applies those settings to the various classes. The function
that reads the command line doesn't need to know where the settings
eventually end up, and the function that applies the settings doesn't
need to know where they come from. All the coupling between settings and
classes is in one place, the second function, instead of scattered all
over your code.



--
Steven
.



Relevant Pages

  • Re: What is common practice?
    ... It is a question of style, Jim, but I don't like globals because: ... They lose their value when you reset your code, ... I also prefer to store these configuration settings/values as records instead of fields in this table. ... If you have a 1-record table which contains various settings for an application, and those settings are used frequently in different functions of the app, say via a function which opens the tbl_Settings recordset and returns the appropriate field, is it more common to run the function every time a setting is needed, or to use a global variable, and use the function only once at startup to assign the variable value. ...
    (microsoft.public.access.formscoding)
  • Re: Global Variables
    ... I have a global "set" structure for all the settings, ... I really don't see a better way than this - globals and all - although ... programming paradigm, rather than the more usual C imperative ... You are structuring your code as a set of state machines - C is just the syntax you use to write it. ...
    (comp.arch.embedded)
  • Re: Global Variables
    ... heavily on global variables. ... I have a global "set" structure for all the settings, ... All the state machines have access to all the settings and status ... I really don't see a better way than this - globals and all - although ...
    (comp.arch.embedded)
  • Re: Need help in Global variable in c
    ... how can I declare the global variable so that it can be set/get by ... you should avoid globals if possible. ... settings). ... The C language does not specify program behavior in ...
    (comp.lang.c)
  • Re: VS .NET, violates listing order in "Additional Include Directories"
    ... The .cpp file in question does not further qualify the name of the header ... <FileConfiguration ... > copied to file settings during the conversion. ...
    (microsoft.public.dotnet.languages.vc)