"Don't poke yourself in the eye."
"Doctor, it hurts when I slice through my eye with a chainsaw."

Although the docs you linked to are a bit over-the-top (quite an unfortunate thing in such a core module), they make a good point:

To provide the capability to set/get class-wide settings, it is best instead to provide accessors as subroutines or class methods instead.

The docs said, "Don't do X, do Y instead" and you used them to justify, "Since I can't do X, I'll do W" where "W" is a much worse idea than "X".

What you are doing is equivalent to having public attributes in a class. That makes for pretty bad class design (of course, some people have a hard time even conceiving of class design without the equivalent of public attributes; for example, take a critical look at Moose ;).

I'll let you struggle with whether you should abandon exposing global variables for your interface and replace them with global subroutines instead. There can certainly be advantages to that. But I won't try to scare you into such a decision with over-the-top proclamations. "Trust me". (:

... the docs seemed to be pretty emphatic that variable names should not be exported, so I was using full qualification instead.

But the variables the Exporter docs warn against exporting are package variables (AFAIU, the only variables that can be exported by the module in question), i.e., global variables, which are commonly acknowledged to have the potential "horrible effects at-a-distance" also referred to in the docs.

Your OPed question seems to boil down to "How can I use global variables without endangering my sanity?". The generally accepted short answer is "You can't!". (Remember: There is no Sanity Claus.)

You are right in thinking that I am concerned with global variables. I don't have a problem with using global variables for things that genuinely are global. Typically I read or generate these at the start of my code and then never change them, so I'm not particularly concerned for my sanity in that regard. I intended my OP question to be along the lines of "how do I avoid typos creating global variables I didn't want". If I can't do that, I have genuine fears for my sanity. :-)

Regards,

John Davies

davies:

Then I'd use the reply from tye using Exporter. It'll let you mark the globals you want to be accessible, and then let you import them into the local namespace. If you typo it, then you'll get a message to the effect that "module foo doesn't export variable bar".

...roboticus

When your only tool is a hammer, all problems look like your thumb.