my %self = %{$_[0]} if ref $_[0];
[download]

has been deprecated and never really did what you think. See the end of Statement Modifiers in perlsyn about the behaviour or the lack of definedness.

As previously mentioned, using a variable that was conditionally defined is not valid Perl, but the compiler does not flag it as an error. I shall suggest alternatives.

The problem can be eliminated from

sub new {
   my $class = shift;
   my %self = %{$_[0]} if ref $_[0];
   ...
}
[download]

by writing it as

# Class->new();
# Class->new({ k=>v, ... });
sub new {
   my $class = shift;
   my %self = ref $_[0] ? %{$_[0]} : ();
   ...
[download]

Better yet, allow the curlies to be omitted for free.

# Class->new();
# Class->new({ k=>v, ... });
# Class->new( k=>v, ... );
sub new {
   my $class = shift;
   my %self = ref $_[0] ? %{$_[0]} : @_;
   ...
}
[download]

I always found using the curlies around named args silly. Sounds like a premature optimisation that does little more than make the code noisier.

There's also the following which doesn't allow hash refs at all:

# Class->new();
# Class->new( k=>v, ... );
sub new {
   my ($class, %self) = @_;
   ...
}
[download]

Thank you for this very good pointer to the documentation. Here be dragons, indeed.

From perlsub:

"A my has both a compile-time and a run-time effect. At compile time, the compiler takes notice of it. The principal usefulness of this is to quiet use strict 'vars' , but it is also essential for generation of closures as detailed in perlref. Actual initialization is delayed until run time, though, so it gets executed at the appropriate time, such as each time through a loop, for example."

use strict 'vars' is checked at compiletime. Yet at compiletime, the compiler cannot know what the condition will be. It has to assume that under some conditions the variable will be declared, and that being the case, it must squelch the stricture complaint.

I understand that it does squelch the stricture complaint, but must it? I would suggest that it could, as an alternative, assume that under some conditions the variable might not be declared, and complain. It is supposed to be strict, after all.

The variable is declared. It might just not be initialized. The two are distinct, and strict is only about declaration.

Corion explained that it's proper for strict not to give an error, but Perl could certainly emit a warning or throw an error.

The only complication would be backwards compatibility. People rely on the behaviour of a conditionally executed my even though the docs have long warned against it.

sub foo {
   my $x if 0;
   print ++$x, "\n";
}

foo() for 1..3;
[download]

1
2
3
[download]

Note that using the hardcoded zero there warns Deprecated use of my() in false conditional.

I've never liked mixing my and modifiers before, and reading this thread has taught me why. I like to always give explicit initializations, so I end up writing that like

my %x = (@_ and ref($_[0]) eq 'HASH') ? %{ $_[0] } : ();
[download]

- doug

The person who was talking about "initialized" versus "declared" was factually incorrect. Please look carefully at the code, and the results.

The variable is NOT being "my'ed" - and the result is that you get a local variable with the same behavior as a *global* (%x is only being "declared" once, and a reference to x returns the same address). Incredible that two "seemingly" locally scoped variables can have the same reference!

This is broken, plain and simple. my should have precedence. if someone say my $x = 1 if $y ... $x should be 1. declared and either "1" or "undefined". Not "global". That's wonky.