Re^3: Managing capture

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 :)

Comment on Re^3: Managing capture

Replies are listed 'Best First'.
Re^4: Managing capture by jbert (Priest) on Feb 19, 2013 at 13:01 UTC
> 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.	[reply]
Re^5: Managing capture by Anonymous Monk on Feb 19, 2013 at 13:19 UTC
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	[reply]
Re^4: Managing capture by Anonymous Monk on Feb 19, 2013 at 12:52 UTC
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 :)	[reply]
Re^5: Managing capture by Anonymous Monk on Feb 19, 2013 at 14:06 UTC
on second thought, that isn't the best starting point, otoh, Perl::Critic::Policy::Subroutines::ProhibitNestedSubs might be :)	[reply]

In Section Seekers of Perl Wisdom