To Moose or not To Moose.. ?

PerlSufi has asked for the wisdom of the Perl Monks concerning the following question:

Hello Monks,
I wrote a module recently for work that I was also considering uploading to CPAN. I am still unsure of the name space, too. Anyways, after an insightful peer review, my essential question is: should I use Moose at all? I understand that this is a pretty small module- which may mean making the dependency silly. The module will take a country code from the user and return a status for it. I considered using the Locale::Country name space, but I'm not a huge fan of how it is used for getting country codes: https://metacpan.org/pod/distribution/Locale-Codes/lib/Locale/Country.pod
Any insight is greatly appreciated :)

package My::Module;

use strict;
use warnings;
use Moose;
use namespace::autoclean;
use Carp;

use feature 'switch';

has country_code => (
    is       => 'rw',
    isa      => 'Str',
    required => 1,
);

has sanction => (
    is      => 'ro',
    isa     => 'Bool',
    lazy    => 1,
    writer  => 'set_sanction',
    reader  => 'get_sanction',
    default => 0,
);

sub status {
    my $self         = shift;
    my $country_code = shift;

    given ($country_code) {
        when (m/MMR|MM/) { $self->set_sanction(1) }
        when (m/IRN|IR/) { $self->set_sanction(1) }
        when (m/CUB|CU/) { $self->set_sanction(1) }
        when (m/SSD|SS/) { $self->set_sanction(1) }
        when (m/PRK|PK/) { $self->set_sanction(1) }
        when (m/SYR|SY/) { $self->set_sanction(1) }
        when ( !defined ) {
            croak "Country Code undefined";
        }
    }
    my $result = $self->get_sanction;
    return $result;
}

__PACKAGE__->meta->make_immutable;

1;
[download]

Comment on To Moose or not To Moose.. ? Download Code

Replies are listed 'Best First'.
Re: To Moose or not To Moose.. ? by Your Mother (Archbishop) on Jun 09, 2014 at 17:59 UTC
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]	[reply] [d/l]
Re^2: To Moose or not To Moose.. ? by PerlSufi (Friar) on Jun 09, 2014 at 20:51 UTC
Thanks, Your Mother. I'll definitely implement something like that instead :)	[reply]
Re: To Moose or not To Moose.. ? by boftx (Deacon) on Jun 09, 2014 at 18:02 UTC
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.) You must always remember that the primary goal is to *drain the swamp* even when you are hip-deep in alligators.	[reply] [d/l]
Re^2: To Moose or not To Moose.. ? by perlfan (Parson) on Jun 09, 2014 at 20:48 UTC
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.	[reply]
Re^3: To Moose or not To Moose.. ? by arkturuz (Curate) on Jun 10, 2014 at 08:30 UTC
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.	[reply]
Re^2: To Moose or not To Moose.. ? by PerlSufi (Friar) on Jun 09, 2014 at 20:52 UTC
Good call, boftx - thanks. I'll do if/else statements for now -along with the export sub idea..	[reply]
Re^3: To Moose or not To Moose.. ? by boftx (Deacon) on Jun 09, 2014 at 20:58 UTC
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.	[reply] [d/l]