In retrospect, I think using getters and setters is probably better than exposing variables.

That's one way to do it, but I would actually recommend against that and suggest two alternatives instead. The reason is that if you simply encapsulate a global in getters/setters, then it's still a global, meaning you have the issue that one piece of code using your module might affect a different piece of code using the same module without meaning to, and also, if you don't use a package variable (our), that means that you're taking away the ability of users to use local to try and mitigate that effect.

So instead, my suggestions would be to just use an our variable, either that or make the module OO and make this variable a property of the object. That means that different pieces of code can change their settings on their objects without affecting each other at all.

I agree with your suggestion to make the module OO -- which means it's time to bite the bullet and learn how to write OO Perl. :-) I know there are various CPAN modules that support it; do you have a recommendation?

Perl OO, at its simplest, actually doesn't involve that much boilerplate so that IMHO it's worth it to learn that - see my example below as well as perlootut and perlmod (Update: and perlobj). But when I do use a module, I typically go for Moo.

package Foo;
use warnings;
use strict;
sub new {
    my ($class, $bar) = @_;
    my $self = { bar => $bar };
    return bless $self, $class;
}
sub foo {
    my $self = shift;
    print "Bar=", $self->{bar}, "\n";
}
1;
[download]

«…how to write OO Perl…various CPAN modules …a recommendation…»

I could imagine that Class::Tiny and Role::Tiny would appeal to you. You can find a potentially quite entertaining example here: Yet another example to get URLs in parallel. For an even more purist approach and for further inspiration see Object::Tiny and Role::Basic. See also Class::Method::Modifiers.

Best regards, Karl

.

«The Crux of the Biscuit is the Apostrophe»