SUMMARY

In this recipe, we begin to delve into the wonder of meta-programming. Some readers may scoff and claim that this is the arena of only the most twisted Moose developers. Absolutely not! Any sufficiently twisted developer can benefit greatly from going more meta.

Our goal is to allow each attribute to have a human-readable "label" attached to it. Such labels would be used when showing data to an end user. In this recipe we label the url attribute with "The site's URL" and create a simple method showing how to use that label.

The proper, modern way to extend attributes (using a role instead of a subclass) is described in Moose::Cookbook::Meta::Recipe3, but that recipe assumes you've read and at least tried to understand this one.

META-ATTRIBUTE OBJECTS

All the attributes of a Moose-based object are actually objects themselves. These objects have methods and attributes. Let's look at a concrete example.

Internally, the metaclass for Point has two Moose::Meta::Attribute. There are several methods for getting meta-attributes out of a metaclass, one of which is get_attribute_list. This method is called on the metaclass object.

The get_attribute_list method returns a list of attribute names. You can then use get_attribute to get the Moose::Meta::Attribute object itself.

Once you have this meta-attribute object, you can call methods on it like this:

print $point->meta->get_attribute('x')->type_constraint;
=> Int

To add a label to our attributes there are two steps. First, we need a new attribute metaclass that can store a label for an attribute. Second, we need to create attributes that use that attribute metaclass.

This looks like a normal attribute declaration, except for two things, the metaclass and label parameters. The metaclass parameter tells Moose we want to use a custom metaclass for this (one) attribute. The label parameter will be stored in the meta-attribute object.

The reason that we can pass the name Labeled, instead of MyApp::Meta::Attribute::Labeled, is because of the register_implementation code we touched on previously.

When you pass a metaclass to has, it will take the name you provide and prefix it with Moose::Meta::Attribute::Custom::. Then it calls register_implementation in the package. In this case, that means Moose ends up calling Moose::Meta::Attribute::Custom::Labeled::register_implementation.

If this function exists, it should return the real metaclass package name. This is exactly what our code does, returning MyApp::Meta::Attribute::Labeled. This is a little convoluted, and if you don't like it, you can always use the fully-qualified name.

This is a bit of defensive code. We cannot depend on every meta-attribute having a label. Even if we define one for every attribute in our class, a subclass may neglect to do so. Or a superclass could add an attribute without a label.

We also check that the attribute has a label using the predicate we defined. We could instead make the label required. If we have a label, we use it, otherwise we use the attribute name:

The get_read_method is part of the Moose::Meta::Attribute API. It returns the name of a method that can read the attribute's value, when called on the real object (don't call this on the meta-attribute).

CONCLUSION

You might wonder why you'd bother with all this. You could just hardcode "The Site's URL" in the dump method. But we want to avoid repetition. If you need the label once, you may need it elsewhere, maybe in the as_form method you write next.

Associating a label with an attribute just makes sense! The label is a piece of information about the attribute.

It's also important to realize that this was a trivial example. You can make much more powerful metaclasses that do things, as opposed to just storing some more information. For example, you could implement a metaclass that expires attributes after a certain amount of time: