how 'bout some horn?

Day two of training today. I had to run off early, but not before getting a crash course in Moose. I’ve been watching Moose for a couple of years, and have a project in mind for it, but haven’t got around to doing anything with it yet. Doing a few basic exercises with it was awesome just to see what it can do, but I did manage to get frustrated by three things within the first ten minutes.

1. The first thing I noticed is that every attribute accessor created is publically available. There isn’t really a way to make an attribute that is read/write from inside the class but read-only from outside. The fine manual suggests this:

has 'attr' => (
    is     => 'ro',
    writer => '_set_attr',
);

This works ok, but its still possible for code outside the class to call _set_attr directly. Until we get lexical subs its impossible to make the writer method invisible to the outside world, but until then I’d still like it to be possible for Moose to produce an accessor that can check its caller.

In a similar vein, its not possible to create proper protected or private attributes. Private attributes can sort of be done by assigning directly to the object hash:

$self->{attr} = 1;

I don’t like this because it because it makes assumptions about the internal implementation of the objects (and with Moose I’d like to remain as ignorant as possible on this point), but also because it provides no type or constraint checking.

Protected attributes (that is, attributes private to a class and its subclass) seem to be completely impossible.

1. By default, a Moose class quietly accept any and all parameters passed to its constructor, regardless of whether or not they correspond to an attribute in the class or its parents. This confused me for a moment as I’ve come from Params::Validate which allows you to declare parameter types and constraints much like Moose attribute declarations, but dies if you provide a parameter that is not declared. The fine inhabitants of #moose on irc.perl.org pointed me at MooseX::StrictConstructor, which does what I want - dies if undefined parameters are provided.

It gets better though. I was declaring an attribute that I wanted to be impossible to initialise via the constructor as I planned to set its initial value in BUILD, and to allow the user to provide a value only to ignore it is confusing. The manual explains that specifying init_arg => undef in the attribute definition will arrange for that parameter passed to the constructor to be ignored, but again, it does it quietly.

It turns out (again via #moose) that combining MooseX::StrictConstructor with init_arg => undef yields the desired results. I can live with that, but I would never have anticipated that result from the documentation. Hmph.

1. Moose doesn’t provide any syntactic sugar for class attributes/methods. A quick search just now turns up MooseX::ClassAttribute which will probably be as much as I’ll need, at least initially, but I was surprised that core Moose didn’t have anything for this. Are class attributes so uncommon?

At the end of the day though, these are all pretty minor nits. Moose is awesome. Its very actively maintained and developed by a number of incredibly smart people, so its not going away any time soon. I’m looking forward to having the time to do something serious with it.