Re^2: Better way to dereference a shifted hashref arg?

This code is almost always wrong:

UNIVERSAL::isa( $_[ 0 ], 'HASH' )

Besides breaking polymorphism, it's unreliable:

my $x = bless \(my $y), 'HASH';

Use Scalar::Util's reftype() instead.

Comment on Re^2: Better way to dereference a shifted hashref arg? Select or Download Code

Replies are listed 'Best First'.
Re^3: Better way to dereference a shifted hashref arg? by tlm (Prior) on Jun 15, 2005 at 18:04 UTC
Thanks++ for the pointer. Interestingly, a few months ago I would have used `ref $_[ 0 ] eq 'HASH'`, but I switched to using `UNIVERSAL::isa` upon reading the advice of some high-ranking monk (can't remember who, though), who deprecated such use of `ref` because it failed on blessed references. My point is that sometimes best practices in Perl seem to be a moving target. More than once I have seen convincing arguments for why stuff that appears in the Perl docs is actually bad programming (e.g. using `AUTOLOAD` for defining accessors; making constructors dual class/object methods; using INIT for initialization code). I realize that this is in part due to the fact that the docs are contributed by users, who may not know any better, and also because Perl is a "work in progress," but I wonder how Perl compares in this regard with other languages, and whether this uncertainty on best practices deters people from choosing Perl as a language for development. Maybe TheDamian's upcoming best practices book will put a stop to that, or at least slow down the mutation rate for best practices. the lowliest monk	[reply] [d/l]

Replies are listed 'Best First'.

Re^3: Better way to dereference a shifted hashref arg?
by tlm (Prior) on Jun 15, 2005 at 18:04 UTC

Thanks++ for the pointer. Interestingly, a few months ago I would have used ref $_[ 0 ] eq 'HASH', but I switched to using UNIVERSAL::isa upon reading the advice of some high-ranking monk (can't remember who, though), who deprecated such use of ref because it failed on blessed references.

My point is that sometimes best practices in Perl seem to be a moving target.

More than once I have seen convincing arguments for why stuff that appears in the Perl docs is actually bad programming (e.g. using AUTOLOAD for defining accessors; making constructors dual class/object methods; using INIT for initialization code). I realize that this is in part due to the fact that the docs are contributed by users, who may not know any better, and also because Perl is a "work in progress," but I wonder how Perl compares in this regard with other languages, and whether this uncertainty on best practices deters people from choosing Perl as a language for development.

Maybe TheDamian's upcoming best practices book will put a stop to that, or at least slow down the mutation rate for best practices.

the lowliest monk

[reply]
[d/l]