There's been a lot of traffic these days about my, local and our. I read some threads on this topic in this most venerable monastery, and I'm reading Amelia as well (aka the Camel Book, 3rd Edition), so I'm now quite comfortable saying that I do understand how all of this works, at least technically.

This is all fine from the compiler's point of view. But, I want now to focus on the reader's point of view, for a declaration gives hints to the reader about how the code works. Here are my thoughts about use vars vs. our, willfully exposed to your wisdom and enlightened comments|remarks|flames.

• If I write

      use vars qw/ %OPT $DBH /;
  [download]

  at the top of my code, it's as if I was annoucing aloud: "beware, this module makes use of global variables %OPT and $DBH. They may be referenced anywhere in the code below without further notice". And the reader thinks: "Wow, thanks for warning!". But if the reader fails to read the start of the file and digs right into a sub, he|she will wonder what the heck is this $DBH thingy, and where does it belong, and what other subs use it as well.
• OTOH, our allows to narrow down the "scope" of a global variable. When I read

      our %OPT;
  [download]

  at the beginning of a sub, it means something like "beware, this function might alter the contents of global variable %OPT". But if another sub doesn't state this our declaration, I can be assured that %OPT won't be accidentaly affected. The tradeoff is that the global variables don't show up until they are actually used, which can be way down the source code: you don't know at a glance what globals the module makes use of (btw, is this an issue?).

So, use vars displays a list of all globals for all to see, right at the beginning of the source file, whereas our highlights the parts of the code where the globals might be altered or referenced.

Now, what would be really cool, IMHO, would be to combine the best of both worlds, i.e. say at the beginning of the source file "Here's the list of all our globals, but no block of code will access any one of them unless it explicitly declares so."...

--bwana147