Category Archives: Uncategorized

My first YAPC::NA!

I’m in lovely Madison, WI right now, and will be headed over to my first YAPC::NA tomorrow. The first couple days are the hackathon, at which I think I’m going to work on a Dist::Zilla stash to hold repository related information. There are a bunch of Git related plugins for Dist::Zilla, a couple that I maintain, and a lot of code is duplicated between them; a stash should resolve that.

I hope to meet you all there! 🙂

vim snippet to generate package name from the filename

One thing that that had been particularly annoying me lately, was the ridiculously long package names called for in a certain project of mine. The package names themselves weren’t the problem, it was writing them out. With filenames like lib/App/MediaTracker/TemplateFor/Browser/PrivatePath/libraries/things/, the corresponding package names become very long and very painful very quickly.

Fortunately, I use vim as my editor of choice. Along with the fantastic snipmate vim plugin it is possible to create a snippet that runs a little vim code as part of it:

The snippet should be stored in ~/.vim/snippets/perl.snippets, unless you have things arranged otherwise.

Now, assuming that my filename and package name are the typical parallels, simply typing pkg<tab> will create a proper package line for me, with an absolute minimum of pain. 🙂

Simulating multiple, lazy attributes

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’):


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  🙂