bluefeet Yet another Perl Hacker weblog

Generating Constants in Perl

The other day @ $work I was throwing together a module that creates constants based on a fairly static table in the database. Of course I didn’t want to hard code the contants, I wanted them to be magically created by what was in the database. For the sake of this example I had a table called “toy_categories” where each record has a unique ID (toy_category_id) and a name that can only be letters and underscores. The data would look something like:

And the resulting constants would look something like this:

If you read the core perl documents you might be lead to think that the constant pragma is the way to go. This is not the case – just because a particular library is distributed with Perl does not mean its a good tool, instead it usually means that the library cannot be removed or substantially modified for backwards-compatibility reasons. In my experience most core libraries are to be avoided – there are much better solutions on CPAN.

So, the CPAN solution to constants is Readonly. This module hooks in to Perl’s ability to mark a variable as read-only, much like how variables can be flagged as tainted or scalars as UTF. Make sure you grab Readonly::XS as well to get the full benefit of read-only variables without the performance hit.

So, if you were to create a module for these constants you might do something like this:

And then in some module you can access these constants:

Now, like I said, I don’t want to hardcode the constants. I want them to be dynamically created by records in my toy_categories table which resides in my database. Its actually pretty simple to do this with some tricky evals:

What’s going on here? Let’s start at the top:

This is the least intrusive way of using exporter and doesn’t pollute your namespace nearly as much as ‘use base qw( Exporter );’ does and is friendlies to other modules.

Replace this with whatever you use to get a DBI database handle. Take a look at DBIx::Connector for a great alternative to doing this directly with DBI.

I’m a big fan of writing my DBI selects in this fashion with bind_columns() because it tends to be the fastest way to get the data (versus fetchrow_hashref, etc) and tends to lead to the simplest code within the while loop since it just needs to use $id and $name versus $row->{$id} and $row->{name} (for example).

While all of the code within _export_variable() could just be inlined right in the spot, that’s bad design. If you can get a piece of your code generalized and moved to a subroutine, do it.

Constants should always, due to convention, be uppercase. It is very important that you code to popular conventions because other people will most likely be working on your code later and if you come from a common expectation of how various things are done they will have an easier time ramping up to your code. I try to code to the Modern Perl / CPAN conventions.

This bit of code was taken from nothingmuch’s blog entry where he announces Try::Tiny which provides a safe way to handle eval errors. Read up there if you want to understand why the code was written this way.

While this code is several blocks deep in scope, this constant will exist in the package’s scope since it is being declared with ‘our’.

That’s it. After this was implemented I thought it was so useful, simple, but requiring the knowledge of a few tricks, that I’d share it with ya’all. Enjoy!