in reply to Re: My globals are visable; but undef'ed
in thread My globals are visable; but undef'ed

For counterpoint, using our is perfect for the OP's task.

By lexically scoping all his wide-scoped package vars, and reducing their visibility to just those places where they are used--prior to splitting the monolithic script into modules--it becomes far easier to identify which variables have to be passed to what subroutines. And that makes the second stage of the process, passing them as parameters, far easier.

As an intermediate step in a refactoring process, lexically scoping the globals is far better than C&Ping the same a huge block of global declarations at the top of every module.

Lexically scope them in the big file first. Make sure everything still works. Split the function into modules--perhaps using the new found knowledge of what routines are dependant upon which globals as an aid to deciding what should go with what--and check again everything still works. Then set about passing those variables through parameters. A totally sane and logical refactoring process.

And for singletons they are perfect too. Even if you do leave them declared at the package scope level.


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."
  • Comment on Re^2: My globals are visable; but undef'ed