The current stable version of Perl is 5.18.0 … but for very good reasons, Koha doesn’t require the latest and greatest. For a very long time, Koha required a minimum version of 5.8.8. It wasn’t until October 2011, nearly four years after Perl 5.10.0 was released, that a patch was pushed setting 5.10.0 as Koha’s minimum required version.<\/p>\n
Why so long? Since Perl is used by a ton<\/strong> of core system scripts and utilities, OS packagers are reluctant to push ahead too quickly. Debian oldstable has 5.10.1 and Debian stable ships with 5.14.2. Ubuntu tracks Debian in this respect. RHEL5 ships with Perl 5.8 and won’t hit EOL until 2017<\/em><\/strong>.<\/p>\n RHEL5 takes it too far in my opinion, unless you really need that degree of stasis — and I’m personally not convinced that staying that far behind the cutting edge necessarily gives one much more in the way of the security. Then again, I don’t work for a bank. Suffice it to say, if you must run a recent version of Koha on RHEL5, you have your work cut out for you — compiling Perl from tarball or using something like Perlbrew<\/a> to at least get 5.10 is a good idea. That will still leave you with rather a lot of modules to install from CPAN.<\/p>\n But since we, as Koha hackers, can count on having Perl 5.10, we can make the most of it. Here are a few constructs that were added in 5.10 that I find particularly useful for hacking on Koha.<\/p>\n The defined-or operator, or<\/p>\n rather than<\/p>\n or (horrors!<\/a>)<\/p>\n Is this just syntactical sugar? Sure, but since Koha is a database-driven application whose schema has a lot of nullable columns, and since use of the Perl This lets you give a name to a regular expression capture group, allowing you to using the name rather than (say) rather than<\/p>\n There’s a bit of a trade-off with this because the regular expression is now a little more difficult to read. However, since the code that uses the results can avoid declaring unnecessary temporary variables and is more robust in the face of changes to the number of capture groups in the regex, that trade-off can be worth it.<\/p>\n The There are some constructs that were added in Perl 5.10, including the Defined-OR operator<\/h3>\n
\/\/<\/code>, returns its left operand unless its value is undefined, in which case it returns the right operand. It lets you write:<\/p>\n\r\nmy $a = get_a_possibly_undefined_value();\r\n$a \/\/= '';\r\nprint \"Label: $a\\n\"; # won't throw a warning if the original value was undefined\r\n<\/pre>\n
\r\nmy $a = get_a_possibly_undefined_value() \/\/ '';\r\n<\/pre>\n
\r\nmy $a = get_a_possibly_undefined_value();\r\n$a = '' unless defined($a);\r\n<\/pre>\n
\r\nmy $a = get_a_possibly_undefined_value();\r\n$a ||= ''; # if $a started out as 0...\r\n<\/pre>\n
warnings<\/code> pragma is mandated<\/a>, it’s a handy one.<\/p>\nNamed capture buffers<\/h3>\n
$1<\/code>, $2<\/code>, etc. For example, you can write<\/p>\n\r\nif ($str =~ \/tag=\"(?
\r\nif ($str =~ \/tag=\"([0-9]{3})\"\/ ){\r\n print $1, \"\\n\";\r\n}\r\n<\/pre>\nUNITCHECK blocks<\/h3>\n
UNITCHECK<\/code> block joins BEGIN<\/code>, END<\/code>, INIT<\/code> and CHECK<\/code> as ways of designating blocks of code to execute during specific points during the compilation process for a Perl module. UNITCHECK<\/code> code is executed right after the module has been compiled. In the patch I’m proposing for bug 10503<\/a>, I found this handy to allow module initialization code to make use of functions defined in that same module. <\/p>\nWarning, warning!<\/h3>\n
given<\/code>\/when<\/code> keywords and the smart match operator ~~<\/code>, that are deprecated as of Perl 5.18. Consequently, I will say no more about them other than this: don’t use them! Maybe the RHEL5 adherents have a point after all. <\/p>\nShare this:<\/h3>