Re^3: UPDATED, mostly solved: separation of define + assignment different from combination?

There is no bug, everything is working as it should, warnings is doing its job

Well, first of all you made mistake, the line 6 is where the assignment is done. Second, if you separate the assignment from localizing, then no warning is produced. According to documentation, there should be no difference. Whether one writes

local(*FUNC) = sub {};
[download]

local(*FUNC);
*FUNC = sub {};
[download]

things should be the same. But they are not. First one produces warning, second one - not. That is why I said, that it might be considered a bug.

Comment on Re^3: UPDATED, mostly solved: separation of define + assignment different from combination? Select or Download Code

Replies are listed 'Best First'.
Re^4: UPDATED, mostly solved: separation of define + assignment different from combination? by Anonymous Monk on Feb 13, 2014 at 08:02 UTC
Well, first of all you made mistake, the line 6 is where the assignment is done. :) Second, if you separate the assignment from localizing, then no warning is produced. um, put that in the code? `use warnings; sub RO { warn "RO" } sub SHAM { warn "SHAM" } RO(); { local RO = sub { warn "BO" }; RO(); } SHAM(); { local SHAM; SHAM = sub { warn "BO" }; SHAM(); } RO(); SHAM(); __END__ RO at - line 2. Subroutine main::RO redefined at - line 5. BO at - line 5. SHAM at - line 3. BO at - line 7. RO at - line 2. SHAM at - line 3.` [download] So, that kinda makes sense to me, when its redefined, you get warning When its undefined, then its defined , you get no warning So , to see if its a bug , I look at what warnings says which is `Subroutine %s redefined (W redefine) You redefined a subroutine. To suppress this warning, say { no warnings 'redefine'; eval "sub name { ... }"; }` [download] So my new code snippet is `$ perl -le " use warnings; sub foo { warn 1 } foo(); local foo; sub f +oo { warn 2 } foo(); " Subroutine foo redefined at -e line 1. 2 at -e line 1. Undefined subroutine &main::foo called at -e line 1.` [download] Hmm, at compile time its redefined, but at run time its undefined Oh right, eval `$ perl -le " use warnings; sub foo { warn 1 } foo(); local foo; eval +q{sub foo { warn 2 }}; foo(); " 1 at -e line 1. 2 at (eval 5) line 1.` [download] no redefined warning is given And third take round trip `$ perl -le " use warnings; sub foo { warn 1 } foo(); { local foo; eva +l q{sub foo { warn 2 }}; foo(); } foo(); " 1 at -e line 1. 2 at (eval 5) line 1. 1 at -e line 1.` [download] no redefined warning is given So , yup, the situation makes sense from a technical point, at the time the new sub is defined, the old sub doesn't exist in the current scope -- current stash -- it doesn't exist Could perl/warnings be made to detect this case? Sure Would it be worth it? I doubt it -- its essentially double checking So, I don't see it as a bug or undesireable; I don't see a compelling reason to change it Cheers	[reply] [d/l] [select]
Re^5: UPDATED, mostly solved: separation of define + assignment different from combination? ( Perl::Critic::Policy::Subroutines::ProhibitSeperatedRedefinition) by Anonymous Monk on Feb 13, 2014 at 08:11 UTC
So as soon as I posted that, I thought surely there should be some kind of critic policy, and before checking first type, Perl::Critic::Policy::Warnings::SubroutineRedefinedUndefinedDefined After checking I find three relevant ones Perl::Critic::Policy::Variables::RequireInitializationForLocalVars - Use my instead of local, except when you have to. Perl::Critic::Policy::Variables::ProhibitLocalVars - Write local $foo = $bar; instead of just local $foo; So my new candidate is *Perl::Critic::Policy::Subroutines::ProhibitSeperatedRedefinition - prohibit that which gets by warnings `sub foo { ... } local foo; foo = sub { };`* Should be fairly trivial to write since Perl::Critic::Policy is xpaths This train of thought firmly establishes in my mind that this situation isn't warnings territory	[reply] [d/l]