Moose - Tag - blog::weyl.io

MX::AttributeShortcuts -- now with Moo-style type constraints

chris@weyl.io (Chris Weyl) — Wed, 08 Apr 2015 00:00:00 +0000

I just released MooseX::AttributeShortcuts 0.028; it incorporates Moo-style type constraints.

…largely because I needed to relax, and wrote MooseX::Meta::TypeConstraint::Mooish :)

That means you can now pass a coderef to has() in isa that, like with Moo, dies on validation failure and lives on validation success:

# easiest is via AttributeShortcuts
use MooseX::AttributeShortcuts 0.028;

has foo => (
  is => 'rw',
  # $_[0] == the value to be validated
  isa => sub { die unless $_[0] == 5 },
);

Cheap Caching with AutoDestruct

chris@weyl.io (Chris Weyl) — Fri, 25 May 2012 00:00:00 +0000

I’ve seen a couple references lately to using lazy attributes as a form of caching. This is a great approach to thinking about lazy attributes, as they share a number of characteristics with traditional caching: you only have to build a (potentially) expensive value once, and then only when you actually need it.

But what about when that lazily generated value is too old to trust?

A lazy attribute isn’t going to help you much then, as your instance is quite happy to keep on returning the same value forever once it has been built, unless you clear or change it manually. This is no good when, say, you’ve run a database query and you can really only expect your painfully contorted query to get the twitter ids of all the left handed Justin Beiber fans north of the Mason-Dixon line who own hypo-allergenic cats to be valid for, oh, say 55 minutes or so.

You could add an attribute to store the age of the value generated for the lazy attribute and check it either manually (boring!), or by wrapping the reader method (less boring, but still, unsightly).

Ok, method modifiers can be fun, but still… That’s a lot of annoying little code that, well, isn’t Moose there to help reduce that sort of code in our lives?

What we’re running into here is that while we implement one part of a cache (generate once, return many), lazy attributes don’t have any internal logic to determine when a value is no longer good. They don’t even have any concept of that, just “someone needed my value, so we’re going to get it and hang on to it until told otherwise”.

This is just the sort of behaviour an attribute trait can alter.

The MooseX::AutoDestruct Moose attribute trait allows us to specify an expiration date for our stored values. We can specify a time-to-live option at attribute creation, and then every time a value is set, the set time is stored. Every time the value is accessed, the attribute checks to make sure the value isn’t older than the set time to live, and if it is, clears the value. This allows the lazy value generation to kick in once more, without requiring any extra effort on the part of the user – just as one would expect.

Simulating multiple, lazy attributes

chris@weyl.io (Chris Weyl) — Tue, 08 May 2012 00:00:00 +0000

Lazy attributes are wonderful. They allow us to postpone generating attribute values for any number of reasons: it’s expensive and we don’t want to do it unless we need it, it should be initialized after instantiation because it depends on other attributes, etc. And it does this without our having to worry about the value being around: if we need it, it’ll be generated on the fly without any extra effort on our part.

As an example, let’s say we have a simple config file that defines key/value pairs. We need to find out the author’s name, which has the key ‘author’ in the config file. We could create a lazy attribute as such:

Simple, yes? Now, whenever you need the authors name, you have it.

So, let’s now say that a couple days later, you realize that you also need to get the author’s email from the config file (key ’email’):

Voila!

Except… Hm. We’re now loading and parsing the config file twice. Though it’s likely to be very low cost to do that (assuming a local, simple config file on the filesystem), it still feels wrong. Besides, what happens when you run into a situation like this and the base set of data (e.g. what load_config() is returning) is expensive to generate?

There are a couple things we could do here: we could create a config attribute, make it lazy and load the config, then change our attributes to pull their value out of the config attribute; we could create a new class to handle the config, and setup a config attribute that delegates to it; etc, etc. That’s a lot of work, however, and work that doesn’t need to be done if we leverage other parts of Moose correctly.

One of the easy, often overlooked ways to do this is to use the tools Moose itself gives us: native attribute traits and accessor currying.

In the above, we see one attribute being created. Note the is => 'bare'; this keeps the attribute from generating the reader, writer or accessor methods. We’re applying the “Hash” native trait, and using the delegation it provides to create custom accessors that pull from the hash without needing the end user to provide keys to a generic lookup.

Note that with either of these approaches gives us the same interface to someone using our class:

This isn’t always appropriate, but if you ever find yourself with multiple attributes whose values can all be generated through one builder, then this may be a good starting approach.

It’s certainly the laziest one :)