I used to use constant all the time, but not anymore. It requires a relatively recent version of perl, and it loads up a lot of code that isn't really necessary for simple cases. Further, it is rather clunky to use it with anything more complex than a simple scalar constant. For instance, to handle the SITES constant above, I would need to change it to an arrayref and modify the site checking code to derefernce the array. That's extra noise with little appreciable gain. Using a subroutine with an empty prototype (which is what constant does anyway) doesn't add a lot of extra code and it avoids the problems constant creates.

Version 1.0 of constant came out in 1997 so it's not that new :)

Yes, switching from sub XYZ() to constant requires code changes. But for new development, it's a little clearer the intentions of what your sub is there for and that you aren't insane.

My version of constant.pm has about 100 lines of perl, with warnings::register using about 25. Not too much for some code clarity if you ask me.


Play that funky music white boy..

We're probably not going to come to an agreement on this.

Note that a lot of people are still using perl 5.005 (constant.pm was first part of 5.6.0), and it wasn't that long ago that Debian and other GNU/Linux distros started installing something a little more recent by default. IIRC, some FreeBSD system scripts won't run on a more recent perl (this may have changed). So there are still a signifcant number of people out there that aren't even on 5.6.

When I'm coding on my main job, I use newer features of the language without a care, because I know we run a more recent version of perl. However, this script was meant for public consumption, which means avoiding newer things if possible (admittedly, I should also have used -w instead of use warnings).

Additional clarity can be gained with a simple # Constants comment above the subroutines in question. I didn't do this in the above code, but it wouldn't hurt.

----
: () { :|:& };:

Note: All code is untested, unless otherwise stated

For instance, to handle the SITES constant above, I would need to change it to an arrayref and modify the site checking code to derefernce the array.

What are you talking about? You can simply

use constant SITES => qw(foo.com bar.com baz.com);
[download]

and it'll do what you'd expect.

Makeshifts last the longest.

Ahh, I see what I was thinking of: when defining multiple constants on one line, you have to follow the same rules as hashrefs everywhere else (because that's exactly what you're passing to constant.pm). That means using arrayrefs, even when all you really need is an array. As you demonstrated, that isn't necessary when using a single constant.

----
: () { :|:& };:

Note: All code is untested, unless otherwise stated