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

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.

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 { ... }"; }

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.

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.

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.

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

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

Replies are listed 'Best First'.
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