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

So we're still talking about Subroutine main::FUNC redefined? Re^4: UPDATED, mostly solved: separation of define + assignment different from combination? clarify anything for you?

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

Replies are listed 'Best First'.
Re^11: UPDATED, mostly solved: separation of define + assignment different from combination? by perl-diddler (Chaplain) on Feb 14, 2014 at 21:49 UTC
There is no difference in the sequence of when the objects are destroyed, so that doesn't yield much enlightenment. It looks pretty quirky for the given example, regardless of it possibly being valid if FUNC was called within the the defining local statement. I don't see the warning is necessary for this example. However, if, in a NESTED call, a "previous definition" of FUNC exists and theoretically could be called to do some function or return a value, from the "outer, non-nested iteration". In that case, the old FUNC is still around and should be usable in the assignment -- the old value of FUNC would be overwritten/redefined BEFORE the old/outer level FUNC had been completely saved off (which, I'm guessing, can't happen until the end of the 'local' statement. Given that the call to FUNC might not be easily determined while that statement is executing, (multiple local functions could be called, with their existence dependent on external state variables), I'd say the warning is probably necessary, as proving such would seem to be NP-hard.	[reply]

Replies are listed 'Best First'.

Re^11: UPDATED, mostly solved: separation of define + assignment different from combination?
by perl-diddler (Chaplain) on Feb 14, 2014 at 21:49 UTC

It looks pretty quirky for the given example, regardless of it possibly being valid if FUNC was called within the the defining local statement.

I don't see the warning is necessary for *this* example.

However, if, in a NESTED call, a "previous definition" of FUNC exists and theoretically could be called to do some function or return a value, from the "outer, non-nested iteration". In that case, the old FUNC is still around and should be usable in the assignment -- the old value of FUNC would be overwritten/redefined BEFORE the old/outer level FUNC had been completely saved off (which, I'm guessing, can't happen until the end of the 'local' statement.

Given that the call to FUNC might not be easily determined while that statement is executing, (multiple local functions could be called, with their existence dependent on external state variables), I'd say the warning is probably necessary, as proving such would seem to be NP-hard.

[reply]