Plinking Away Part the Fourth
Well my last post trying to work with MooseX::ClassCompositor was a bit of a bust as it is not what I needed. So onto the next one one my list 'MooseX::ShortCut::BuildInstance' so lets have a look and see what this one can do for me.
Well at first glance it seems a hybrid of the last two, it does follows the same basic pattern, give a base class add some roles and then get a instance. With this mod I don't have to build a factory class like I do for MoosX::Facotry but I can supply a base class which I could not do for MooseX::ClassCompositor so things look promising.
This one also has the best documentation but it still is very sparse but informative. The tests are a little more elaborate but still very basic and a funny thing he uses them in the synopsis in the POD haven't seen that often.
So lets give it a try
use MooseX::ShortCut::BuildInstance qw( build_instance );
my $fighter = build_instance(
package => 'RPG::ADD::Player',
superclasses =>['RPG::ADD::Class::Fighter'],
roles =>['RPG::ADD::Character::Ability::Henchmen',
'RPG::ADD::Character::Ability::OpenDoorsOnA'],
name=>'Sir Cumferace',
strength=>18,
exceptional=>91
);
print $fighter->name()."\n";
print "strength=".$fighter->strength();
print " (".$fighter->exceptional().")\n"
if($fighter->can('exceptional'));
print "opens a door on a ". $fighter->open_door_on_a()."\n";
print "opens a barred door on a ".$fighter->open_barred_doors_on_a
if($fighter->can('open_barred_doors_on_a'));
So all I did was add in my 'RPG::ADD::Class::Fighter' class as a 'superclasses' then the roles that are applied via the roles array.
So lets see what I get when I run it
Sir Cumferace
strength=18 (91)
opens a door on a 4
opens a barred door on a 1
So great the same thing that I get with the original and with MooseX::Factory so I guess like all things in perl TMTOWTDI.
Well thats all and good but in the pod he states this warning
Moose (and I think perl 5) can't have two classes with the same name but different guts coexisting! This means that if you build an instance against a given package name on the fly and then recompose a new instance with the same package name but containing different functionality all calls to the old instance will use the new package functionality for execution. (Usually causing hard to troubleshoot failures)
So I tested this and with two instances of the same class the second being
my $fighter2 = build_instance(
package => 'RPG::ADD::Player',
superclasses =>['RPG::ADD::Class::Fighter'],
roles =>['RPG::ADD::Character::Ability::Henchmen',
'RPG::ADD::Character::Ability::OpenDoorsOnA'],
name=>'Sir Loser',
strength=>16,
);
Both still work fine
Sir Cumferace
strength=18 (91)
opens a door on a 4
opens a barred door on a 1
Sir Loser
strength=16
opens a door on a 3
So I think this only counts when you are creating new classes with the 'build_class' I don't really have a use for that so I will ignore it for now.
The package does come with some neat features like 'BuildInstance::instance_count' which might come in handy.
So far it is a two horse race. I will have a never look about on CPAN to see if there are any others as there is more than one way to dress a Moose
The issue isn't so much with multiple Fighter instances (using different attribute settings) sharing the same package name but with different Character types (Fighter, Thief, Magic User) using the same 'package' name. There can be only one composition of superclasses and roles per package name. (cue the Queen soundtrack) Thanks for the review.