From: coachhilton@...
Date: 2006-08-09T04:50:08+09:00
Subject: Re: Global variables considered harmful?


darren kirby wrote:
> Hello all,
>
> I have a Ruby script here that acts like a regular Unix program, including
> accepting a large number of command-line options/arguments. After processing
> some  are simple flags (ie: nil or 1) and some are text/numeric arguments.
> Not all are required, and some must be initialized with a default value. I
> have currently implemented them as globals, as their values are needed
> anywhere in my script, from classes to functions to top-level flow control
> code...
>
> Now I know you are not supposed to rely on globals if you can help it, so I am
> trying to rewrite my script to do away with them. The problem is that there
> are so many command-line switches that simply passing them to the
> class/function(s) that need them would be unwieldy.
>
> So what do I do? I was thinking of creating and populating a new class that
> would act similar to a C 'struct', but it seems to me that this is just a
> different way to do the exact same thing as I have now, except that I would
> have to qualify the variable with a class instance making my script even more
> verbose than it is now...so why shouldn't we use globals again? Is it simply
> the namespace issue or are there other reasons?
>
> Is one global hash better than 15 global scalars?
>
> I am not going to list my code here because it is 500+ lines but if you want
> to see it let me know and I will post it to the web,
>
> Thanks for consideration,
> -d
> --
> darren kirby :: Part of the problem since 1976 :: http://badcomputer.org
> "...the number of UNIX installations has grown to 10, with more expected..."
> - Dennis Ritchie and Ken Thompson, June 1972
Well, this is quite a "can of worms" topic, now isn't it?  For whatever
its worth, here's what I do: I have a base class I've been working on
over time from which I derive all of my other scripts.  In this base
class I have all of the logic to configure the script, from command
line options, to environment vars to config files along with a bunch of
handy helper methods for things like logging and debugging.  The
results of the configuration go into member variables of this base
class, or optionally a hash of properties, and thereby form the context
in which the actual script/application runs.  Sure, these are really
global variables packaged up in the base class but at least they are
encapsulate and the script doesn't know where they came from or how
they got there.  This has worked pretty well for me over time for a
variety of program sizes.

Now then, the direction I've been heading in lately has been toward
"inversion of control" (see
http://martinfowler.com/articles/injection.html for a very nice
presentation of the topic.)  I envision going to a Dependency Injection
pattern some time soon in which the configuration information is
obtained from an inversion control container, as described by Fowler.
But I think I'd only go to this level of "complexity" for true
applications and not for hundren line "scripts".

Hope this helps.

Ken