(Ovid -Rant) Re(2): Using strict with globals

I believe you asked about this a few months back. How's the project going?

Did I? Sheesh. Early Alzheimer's, I guess.

I was pulled from that project to work on projects for which we're actually getting paid. We have an impending rewrite of the original project and my mind wanders back to the original problem without seeming to get anywhere. The code is such an absolute mess that finding clean solutions seems to be a problem. You and suaveant have both suggested a nice solution, but I don't know that it's always practical.

Let's say we download a module from the CPAN, or have received from a vendor, that has periodic updates. If I don't want to keep reapplying a patch to those modules, I need another solution. I suppose I could write modules that grabs those globals and exports them into my namespace without necessarily requiring that I change the original code. I'd like to fix these programs one at a time without risking my breaking anything by adding code to all of the shared modules.

If I have about 40 programs, this seems a bit better because I can convert everything one-by-one without worrying about who's working on what. The problem is that all of those 40 or so programs use globals in %main::. It doesn't matter what package these variables are declared in, they're usually, but not always, qualified as being in %main::. For those programs that don't use strict, a given global might be in main, in might be in that module's namespace.

I suppose I'm just looking at this new project with dread and am ranting here. I've been trying to find a quick and easy solution to a mess of code and I need to just knuckle down and start digging in. I have to just face the fact that there is no magic bullet that will kill this beast. No point in continuing this thread :(

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

Comment on (Ovid -Rant) Re(2): Using strict with globals

Replies are listed 'Best First'.
Re: (Ovid -Rant) Re(2): Using strict with globals by dragonchild (Archbishop) on Jan 04, 2002 at 02:13 UTC
You will be happy to know that you're wrong. In fact, that they all refer to `$main::foo` is going to be a saving grace for you. :-) Consider this: You create a module called Globals.pm It inherits from Exporter You do a global find for all references to `$main::foo` You replace all those with references to the exported variable `$foo` You run the program and it breaks somewhere during compilation (cause you wisely turned on strict). You track those last buggers down within an hour or two. Then, once they're all in one module, you can start the refactoring with an idea of how bad the situation really is. It could be as simple as under 100 variables or it could be 1000's. You simply don't know right now. As for modules ... CPAN modules don't use %main:: and vendor-supplied modules don't use %main::. (Well, if the latter do, then the vendor should go out of business, proving my point. grins) So, you shouldn't have to patch over every time for these. In-house modules ... well, shoot the author and you're good. :-) ------ We are the carpenters and bricklayers of the Information Age. Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re: (Ovid -Rant) Re(2): Using strict with globals
by dragonchild (Archbishop) on Jan 04, 2002 at 02:13 UTC

$main::foo

Consider this:

You create a module called Globals.pm
It inherits from Exporter
You do a global find for all references to $main::foo
You replace all those with references to the exported variable $foo
You run the program and it breaks somewhere during compilation (cause you wisely turned on strict).
You track those last buggers down within an hour or two.

As for modules ... CPAN modules don't use %main:: and vendor-supplied modules don't use %main::. (Well, if the latter do, then the vendor should go out of business, proving my point. *grins*) So, you shouldn't have to patch over every time for these. In-house modules ... well, shoot the author and you're good. :-)

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

[reply]
[d/l]
[select]