I'm ignoring the prototype in this usage because Perl liked it a little better this way. (I put it on while debugging, as I was finding all my typing errors.) Most of my usuages don't ignore it. (I'm still undecided if I like prototypes for this type of case or not.) You do have a point: I can drop the '&' now that I've found all the other typos that were causing me trouble.

I could put it in an module instead of main: But I'd still need it in main and in this scope. I do not want to require external modules (besides the standard) if at all possible: This is for wide distribution within the organization, and I want to have as little barriers as possible to it getting used. (We'll have enough trouble as it is: I expect some of the departments don't even have Perl on their machines...) It needs to look like a simple script to anyone installing and running it.

Are you saying the easiest way to do this is to create an 'output' package and import it into both main and State::Object?

This is for wide distribution within the organization, and I want to have as little barriers as possible to it getting used.

The installer for yours module can install the other module at the same time. That's a simple matter of putting one line in Makefile.PL.

Are you saying the easiest way to do this is to create an 'output' package and import it into both main and State::Object?

Seems simple to me:

use Logger qw( output :err_levels );
[download]

use strict;
use warnings;

package Logger;

use Exporter qw( import );

our @EXPORT_OK = qw(
   LOG_ERROR
   LOG_VERBOSE_ERROR
   LOG_WARNING
   LOG_VERBOSE_WARNING
   output
);

our %EXPORT_TAGS = (
   err_levels => [qw(
      LOG_ERROR
      LOG_VERBOSE_ERROR
      LOG_WARNING
      LOG_VERBOSE_WARNING
   )],
);

use constant {
   LOG_ERROR   => 1,
   LOG_WARNING => 2,
};

use constant {
   LOG_VERBOSE_ERROR   => -LOG_ERROR,
   LOG_VERBOSE_WARNING => -LOG_WARNING,
};

sub output {
   ...
}

1;
[download]

I find it odd that control over whether the warning or error is verbose or not is in the caller's control and not a configuration item.

Update: Added code.

One note: use constant { .. }; requires a moderately recent Perl. This has bit me in the not-to-distant past... (Just a sidenote, since it's not easy to find the error when it happens.)

I find it odd that control over whether the warning or error is verbose or not is in the caller's control and not a configuration item.

The idea is that the caller can define whether a particular message is part of 'verbose' or not, and the configuration will define whether (and possibly how) they are output. So you can ask for errors, warnings, or both, and get either short or verbose versions.

This is fairly early stages in the design on this: I've got little more than a skeleton all in all. Just enough to see how it all works, not so much I can't re-organize it if I think I want to.