Re^3: Managing capture

[Anonymous Monk]

in reply to Re^2: Managing capture
in thread Managing capture

To elaborate on competence, you said Note that the logging could have been added casually, and doesn't look evil on a review diff. except that it should -- when doing reviews you should be checking for cycles, esp with anonymous subs

But I don't really know what you mean by "review diff"

Also, you could write a perlcritic policy, it isn't too hard :)

[Anonymous Monk]

You can base your policy on Perl::Critic::Policy::Variables::ProhibitConditionalDeclarations - Do not write my $foo = $bar if $baz; .

I found it via perlcritic closure -> Closure warning with Perl 5.14?

While using closures isn't exactly a red flag, it should be on the list of traps for code/module evaluation

:) I got my links in :)

[Anonymous Monk]

on second thought, that isn't the best starting point, otoh, Perl::Critic::Policy::Subroutines::ProhibitNestedSubs might be :)

[jbert]

> when doing reviews you should be checking for cycles, esp with anonymous subs

I agree with this very much. But I think it is a hard problem. The intention of this pragma would be to make cycles caused via capture easier to spot in code review.

[Anonymous Monk]

I agree with this very much. But I think it is a hard problem. The intention of this pragma would be to make cycles caused via capture easier to spot in code review.

Its not really that hard :) Devel::Cycle - Find memory cycles in objects

It is easy to modify perlcritic ProhibitConditionalDeclarations to alert yo to closures for a code , and then you can further investigate to decide if they're really trouble, or ok