Re: Perl Critic and 5.6 vs. 5.8
That is not a valid approach. It may shut up P:::C but there are features like our in later versions which one can in best practices use. Do determine your minimum level and put that in. If P::C complains b/c you put use 5.8 in then it is borked --Original Message-- From: Elliot Shank To: raha...@ualr.edu Cc: module-authors@perl.org Sent: Feb 18, 2009 9:46 PM Subject: Re: Perl Critic and 5.6 vs. 5.8 Roger Hall wrote: Three-argument form of open used at line 351, column 4. Three-argument open is not available until perl 5.6. [chop] 2. Does the applicable P::C::Policy take the prereq’d version into account? Put a use 5.005 or other version less than 5.006 at the top of your module and the policies should stop complaining. Sent from my BlackBerry® smartphone with Nextel Direct Connect
Re: ARGH! (was FW: Perl Critic and (honest) hash references)
Ovid wrote: Readonly constants are just easier to use and have fewer gotchas. they have indeed, when you need to access the constants from outside of the module they are declared in (which is a pretty common case). cfr. Foo::Bar::CONSTANT_FIELD vs. $Foo::Bar::CONSTANT_FEILD. the latter fools strict. IMHO, the unconditional sponsoring of Readonly by PBP is just plain wrong. cheers, Aldo
Re: ARGH! (was FW: Perl Critic and (honest) hash references)
- Original Message
From: Aldo Calpini d...@perl.it
Ovid wrote:
Readonly constants are just easier to use and have fewer gotchas.
they have indeed, when you need to access the constants from outside of the
module they are declared in (which is a pretty common case).
It also used to be very common not to use strict or warnings. This doesn't
mean it's a good thing. The module in question should provide a sub or method
to provide access to this data. Java programmers learned long ago not to let
people tough their privates, Perl programmers should learn the same thing.
(For example, when the constant is computed rather than declared, wrapping it
in a sub saves a *lot* of grief -- if you've done that up front and not forced
people to change their APIs).
If you *must* use globals, it's certainly a good thing that they're read-only
but at the very least, do it sanely:
package Some::Module;
use Readonly;
Readonly our $foo = 3;
use Exporter 'import'
our @EXPORT_OK = ('$foo'):
Note that we've been forced to switch from 'my' to 'our' in the Readonly
variable, but now the calling code doesn't need a fully-qualified package name:
use Some::Module '$foo';
print $foo;
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog- http://use.perl.org/~Ovid/journal/
Twitter - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: Perl Critic and (honest) hash references
On Wed, Feb 18, 2009 at 12:58:46PM -0800, Ovid wrote:
Mostly agreed. Objects should be about responsibilities (behavior) and not
so much about state (data). That being said, hashes are notorious for
$gimme-{feild} (note the misspelling)
Tie::Hash::Vivify is useful for detecting this:
my $hashref = Tie::Hash::Vivify-new(sub {
confess(No auto-vivifying (did you mis-spell something?)\n.Dumper(\...@_))
});
I found that excellent module after spending *hours* tracking down a typo
deep in the guts of CPU::Emulator::Z80.
--
David Cantrell | Enforcer, South London Linguistic Massive
Repent through spending
Re: Perl Critic and 5.6 vs. 5.8
On Wed, Feb 18, 2009 at 08:25:39PM -0600, Roger Hall wrote: 1. I should have perl set to a minimum version, shouldn't I? What's the best way to do that? (Makefile?) Yes, see http://wiki.cpantesters.org/wiki/CPANAuthorNotes -- David Cantrell | Cake Smuggler Extraordinaire Irregular English: ladies glow; gentlemen perspire; brutes, oafs and athletes sweat
Re: ARGH! (was FW: Perl Critic and (honest) hash references)
On Thu, Feb 19, 2009 at 09:04:35AM +0100, Aldo Calpini wrote: IMHO, the unconditional sponsoring of Readonly by PBP is just plain wrong. An awful lot of PBP is Just Plain Wrong if you treat it as hard-and- fast rules that should be obeyed all the time. Thankfully, the book makes it clear that it shouldn't be treated that way. -- David Cantrell | http://www.cantrell.org.uk/david engineer: n. one who, regardless of how much effort he puts in to a job, will never satisfy either the suits or the scientists
RE: ARGH! (was FW: Perl Critic and (honest) hash references)
That is primarily due to their special ability to slay powerful beasties. :} Roger -Original Message- From: Aristotle Pagaltzis [mailto:pagalt...@gmx.de] Sent: Thursday, February 19, 2009 10:13 AM To: module-authors@perl.org Subject: Re: ARGH! (was FW: Perl Critic and (honest) hash references) Everyone seems to be looking for silver bullets.
Re: ARGH!
* On Thu, Feb 19 2009, Ovid wrote: Java programmers learned long ago not to let people touch their privates, Perl programmers should learn the same thing. This is one of Java's worst design decisions. A while back, I needed to customize the way URLConnection worked. The parts I needed to touch were private, so I had to copy the source files from the open source java implementation, modify one line, and use my custom library instead of the one bundled with the JVM. All because they said private instead of public, and the runtime insisted on enforcing that restriction. (Sure, they could change the implementation out from under me. I am willing to take that risk. The point is that it should be *my* decision, not the module author's decision.) In general, you should make it clear that internals are at your own risk, but you shouldn't physically prevent access. It just wastes everyone's time, and doesn't make any code more maintainable. (Since I'll just have to cut-n-paste to work around it.) In general, whenever Java does something, you actually want the opposite. This case is no exception. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
