That seems a bit over-engineered…depending on how/where you use it. I would go with something more like this + some sub exporting (one function, probably with a less generic name) before resorting to objects. It’s really just a simple lookup.

package OHAI;
use strict;
use warnings;
use Carp;
our %Status = map {; $_ => 1 }
    qw( MMR MM IRN IR CUB CU SSD SS PRK PK SYR SY );

sub status {
    my $country_code = shift || croak "status requires country code";
    $Status{uc$country_code} || croak "Country code '$country_code' un
+defined";
}

1;

__DATA__

=head1 Do you even Pod, bro?

OHAI - ...

=cut
[download]

Thanks, Your Mother. I'll definitely implement something like that instead :)

I would not use Moose for something so simple. As an aside, I would consider using something other than given, too, since there are still a lot of questions surrounding its status. (Experimental-Details-on-given-and-when.)

I would not use Moose for anything complex either. The deal with Moose not necessarily that it is heavy handed. It has to do with the notion that it is creating a new paradigm and idiomatic system inside of Perl that is actually much more constraining than what Perl already provides itself. Moose provides a Metaobject Protocol on top of Perl's Meta Protocol, so it's actually constraining you in many ways. This doesn't just apply to Moose. It applies to all MOPs. You end up creating gobs of predefined and implied declarations rather than just cleanly creating a set of blessed object interfaces. What you end up with is decidedly not Perl, and I am not sure what the payout is.

What I tend to do if I want to easily create a set of accessors based off of fields names is to do so using one of the many accessor create modules on CPAN. It truly takes very little code to turn a list of field names into some autogenerated get/set methods, so just as often I use my own code snippet to make it happen.

It has to do with the notion that it is creating a new paradigm and idiomatic system inside of Perl that is actually much more constraining than what Perl already provides itself.

This is what you want when doing complex stuff. You can, of course, limit your data and application behavior with plain old Perl, but in the end it's too much work. Perl is not exactly at the top of elegant OO approach by itself. I've done some mildly complex stuff with Moose in the past and it worked great. I'll certainly use it in the future, although there are simpler alternatives these days.

and I am not sure what the payout is

The payout is simpler code, easier to understand at glance, easier to maintain and extend. For simple stuff, Moose is overkill, but for anything complex (in terms of behavior, not just in terms of pure amount of object data, methods etc) Moose is a good solution.

Good call, boftx - thanks. I'll do if/else statements for now -along with the export sub idea..

The code given by Your_Mother has an excellent example of building the hash and then keeping it handy if you are in a persistent environment. I would definitely use something like that.

Update: Anytime I find myself with more than 1 or maybe 2 elsif statements I start thinking about using a hash with keys corresponding to what the condition being tested for is if possible. In broad terms, that is creating a dispatch table.

You must always remember that the primary goal is to drain the swamp even when you are hip-deep in alligators.