Re^4: How Large Does Your Project Have To Be to Justify Using Moose? (modular)

[jgamble]

That's a good question.

Most of the interface of my ancient module is not centered around the attributes (once the information is passed in via new(), that's pretty much it). The majority of the methods are there messing with the object state, and the remaining soon-to-be-implemented-as-plugins methods are there for different types of output. Is Moose the right tool for this?

[Arunbear]

Moose also gives you Roles which seem like a good fit for the "soon-to-be-implemented-as-plugins methods" (there's also a longer explanation of roles).

It also makes delegation very easy to set up (as another more optimal reuse method than inheritance).

Even if the attributes aren't part of the module's interface, Moose will create for you a new() method that lets the attributes be passed in e.g.

package Person;
use Moose;

has 'name' => (reader => '_name');
has 'age'  => (reader => '_age');

sub talk {
   my $self = shift;
   printf "My name is %s and I'm %d years young\n", $self->_name, $sel
+f->_age;
}

package main;

my $bob = Person->new(name => 'Bob', age => 55);
$bob->talk();
$bob->age(1); # dies

And it's nice to be able to see at a glance what the attributes are instead of having to dig into the constructor.

[jgamble]

Moose also gives you Roles which seem like a good fit for the "soon-to-be-implemented-as-plugins methods"...

Hmm. Although it doesn't seem to provide a plugin framework itself. I take it I should be looking elsewhere for a standard, or at least commonly used, way to do that?

[Arunbear]

This question came up recently: Re^3: Inherited Object Constructor Question, though depending on what the plugins do, you may find that Roles can do what is needed without needing a full blown framework.