It doesn't make sense to shove recommendations from "Programming Perl, 4th edition" into the rule set from PBP, for all the reasons described above (different era, different author, different recommendations). Keep them separate, and let the user decide which he wants to apply to his development practices.
]]>But, having said that, don't worship at the Altar of Conway: Despite his accent, charm, movie star good looks, and amazing upper body strength, Damian qualifies what he means by "best".
You might like to re-read Damian's first chapter, or my interview with him in The Perl Review. You shouldn't need a book to tell you what your policies should be. Your experience in your job and in that situation should be your main guidance. Damian just provided some advice and Jeff provided the Perl::Critic framework that was presciently expandable.
I've seen PBP be much more harmful than helpful, losing companies lots of money for me to figure out why their application broke after a PBP zealot added /xsm to every regex.
As for the book update, it doesn't make sense for anyone to spend the huge amounts of time for the money they'll make from it. At every next skill level, a publisher expects to sell only 10% of the lower level. The Alpaca has 1/10th the sales of the Llama. Mastering Perl will have 1/100th the sales. If I weren't already invested in several other Perl titles which subsidize the advance book work, I wouldn't do them.
Damian, like almost everyone else, has to put food on the table. That book never made that much money. The problem is that not enough people will buy his book. O'Reilly are very good about releasing books to authors if they decide against an update. Beyond that, I can't speak for Damian.
The Camel is not the new PBP. It's a different book with different authors who have different preferences and different constraints. Despite the "best practices" in the title of Damian's book, most of that book wasn't about superlative practices. There's no such thing as a best practice outside of any context, and that's the problem with that sort of thinking. It's the wrong place to start. Not only that, best practices are something borne out of long histories of industry practice. You're just not going to get that with anything in Perl. Most things we're doing now will be bad practice in five years.
Randal Schwartz had his own "Perl Second Best Practices" talk, where he counters Damian's preferences with his. As I recall, Dave Rolsky had compiled a list of rebuttals and alternatives to Damian's suggestions.
]]>I wasn't trying to be patronizing, but I bet I've worked with many more publishers than you, and I bet I've worked in more deadly situations than you. So, since we don't know each other, let's not fight about who's dick is bigger. :)
I've pointed you toward what Damian and Randal have said. If you think I'm a twit, that's fine, but the advice I'm passing on comes from them mostly. The problem with authority is that there are so many of them. :)
]]>Regards
Lukas
]]>But, good programmers don't need recursion. :)
]]>Time::Moment can never be "backwards" comparability with DateTime.pm due to DateTime.pm's design.
I did consider to add Panda::Date until I reviewed the source code. Your code isn't thread safe and you require 5.18 to compile it, and your naïve implementation of a date with a time representation due to the broken down representation is just a wasteful! An instance of Time::Moment requires 16 bytes plus the overhead of a scalar allocation and is mostly faster than your implementation that doesn't even support a fractional representation!