1. It's wrong when applied to initializing empty arrays and hashes, so it doesn't "scale" well.
2. I presume a knowledge of people reading my code equal to that contained in my Learning Perl book, and in there, it's clear that a new scalar starts with undef

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

What are your thoughts on using it in constructors of hash or array based objects for purposes of clarity?

For example:

sub new {
    my ($class) = @_;
    my $this = bless {}, $class;
    $this->{foo} = undef;
    $this->{bar} = undef;
    return $this;
}
[download]

Where 'foo' and 'bar' may be initialized during the course of the program, but not at construction. To me, this makes it more clear what an instance of this class consists of. It also can make debugging easier if you are fond of Data::Dumpering as I am.

---

"The dead do not recognize context" -- Kai, Lexx

That seems to be more than a simple declaration, and the semantics would obviously change if you eliminated that line. I don't consider that an equivalent to my "no = undef" principle.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

I prefer:

sub new {
    bless {
        foo => undef,
        bar => undef,
    }, shift;
}
[download]

That may be golfing it too far for your tastes, but the point is still valid. Creating the data structure with the data you want already in it is generally clearer than creating it and then building it up with fixed assignments.