Stephen's Work Ramblings

At the start of 2014 I was working on a project to further improve the LCFG client. When I hit problems with Moose and its memory usage I discovered the excellent Moo framework which provides all the nice bits but is much less heavyweight. As part of the Perl Advent Calendar for 2014 someone has written a great introductory article on using Moo along with Type::Tiny. I’ve learnt a few things, I particularly like the idea of a “type library” as a good way to organize all the local types.

For quite a while now I have wanted to have the ability to apply a Moose role without actually loading any of the associated code. I’ve finally come up with a solution which seems to do exactly what I need.

For a bit of background, Moose roles are what is often referred to in object-oriented programming as “interfaces”. They are used to declare that a class is guaranteed to implement a particular behaviour (attributes and/or methods) as part of its API.

A commonly used role which is available on CPAN is MooseX::ConfigFromFile which is used to declare that a class has the new_with_config and get_config_from_file methods. These are used to set the values of attributes from a configuration file. This works well in conjunction with other roles, such as MooseX::Getopt, which can detect when the ConfigFromFile role is implemented and load the values for attributes from either the command-line or a specified configuration file.

The problem is that the MooseX::ConfigFromFile code is a little bit peculiar and has a dependency on MooseX::Types::Path::Class (and thus MooseX::Types and Path::Class amongst others) which are not usually essential and lead to memory bloat for no good reason.

So, here is my solution, add these two lines:

my $extra_role = Moose::Meta::Role->initialize('MooseX::ConfigFromFile');
__PACKAGE__->meta->add_role($extra_role);

I can use this to state that my own configuration loader module does everything that the MooseX::ConfigFromFile role requires but I do not need to load (or even have installed) the MooseX::ConfigFromFile module file itself. This seems to work equally well when applied to a role or a class.

Some people have questioned the wisdom of basing future software projects on an Object-Oriented programming technology such as Moose (see previous posts for more details on Moose if you don’t know what it is) rather than doing it the good old-fashioned way in pure, unadulterated Perl.

There are always questions to be considered whenever a new piece of software is introduced into the mix. Is it widely used? It is well written? Does it produce comprehensible and maintainable code? Could someone who has not seen it before pick up where someone else left off in the standard “run over by a bus” scenario? Is it likely to scare the living daylights out of anyone who’s never seen it before? I believe that most of these have been answered on the web by the wider Perl community when it comes to Moose. It seems clear, to me, that something like this is the future of all Perl OO programming, particularly given that it is inspired by work being done for Perl6.

In an attempt to show that Moose produces code which is comprehensible, maintainable and in many ways a big improvement over the pure Perl approach. Here’s an example written both ways: Foo.pm and FooMoose.pm. One thing to notice straight away is that the Moose variant is 49 lines long compared to the 114 lines of the standard version. It allows all the standard handling of getting and setting values to be hidden away. The author can then get on with specifying exactly how the class attributes should be defined.

There’s no doubt that the Moose approach is different, it doesn’t look quite like normal Perl but it is a very perl-ish way of programming. Beyond needing to learn a few basic keywords I don’t think there is much in the code which will scare a Perl programmer who has not previously touched Moose. I’d hope that, if anything, Moose should make it easier for future developers to maintain and extend code written in this way.