--- Kevin Hancock <[EMAIL PROTECTED]> wrote:
> Hi Guys
>
> I was hoping this would be a problem because I am struggling with the whole
> scope thing in Perl but here goes.
>
> A section of my code.
>
> require "$LIBRARY_DIR/castime_html.pm";
> use CGI; # load CGI routines
> use strict 'vars';
> my $q = new CGI; # create new CGI object
>
> Problem is $q is not visible to any subs in $LIBRARY_DIR/castime_html.pm.
> Now I am assuming I can pass $q into each sub but that seems silly. $q has
> methods as well as data that I want to use everywhere so I want to pass the
> whole thing not just the data. If I have to pass the entire $q to each sub
> why not just make it global to all?
>
> Why is this a BAD THING?
That's a great question and it really trips up a lot of novice programmers. One of
the Web sites
that I currently have to maintain was developed by a programmer who was in love with
global
variables. There are many, many global variables spread out over about 20 programs
and four or
five libraries. Because we are only maintaining this site and aren't being paid to
rewrite it
(which should be done), I can't correct this problem easily. So what I have is a
bunch of bad
code where I can't change ANY variable names. Further, I have to remember all of the
darned
things. Hmmm, what does $main::state{'sibling'} do? Gosh, I don't recall offhand,
but I know
it's one of the globals that's used.
Globals also cause namespace pollution. If I require a package that exports a bunch
of variables
and functions into my namespace, I had better hope that I'm not using variables or
functions with
the same name. No telling what will happen!
Modules should be reusable. You're requiring a module "casttime_html.pm", that needs
a CGI
object. As a matter of good coding practice, you have two alternatives:
1. Always pass it the CGI object that it needs.
2. Instantiate a new CGI object within it
(probably with a $q = CGI->new("") syntax so it doesn't
clobber any form data).
The problem here is simple: what happens if you need to reuse this module? That's
why you wrote
it, right? If you reuse it with a global, every program that ever rights this will
need to use
the same global variable. What if that doesn't work in the future? You'll either
need to rewrite
the module and all code that depends on it or write a new, essentially identical
module that
doesn't use globals and then constantly synchronize the code in those two modules.
Summary of problems with globals:
1. Many globals are tough to remember
2. Namespace pollution
3. Interfere with code reuse
Incidentally, many people wonder about all of the Perl globals ($_, $| and so on).
Yes, they are
theoretically objectionable, but they really don't suffer the above problems. For one
thing, they
become easier to remember since they are used across many scripts and are virtually
guaranteed not
to change. For another, they don't cause namespace pollution since you were never
going to name a
variable something like $$ (at least you shouldn't be). Also, since they are built
directly into
the language, they don't interfere with code reuse (usually) since they are so well
documented and
understood.
Cheers,
Curtis Poe
=====
Senior Programmer
Onsite! Technology (http://www.onsitetech.com/)
"Ovid" on http://www.perlmonks.org/
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
