Re^2: Managing capture

Replies are listed 'Best First'.
Re^3: Managing capture by Anonymous Monk on Feb 19, 2013 at 12:12 UTC
Competence is always nice sure, but I don't understand how destructors help. They aren't invoked unless an object is destroyed, which it won't be if it paricipates in a cycle. I think you understand pefectly :) If you're accepting callbacks and storing them in an object, you can made a practice of using PadWalker and checking for closures A slightly simpler check could be made using Devel::Refcount but why bother when PadWalker can do it :)	[reply]
Re^4: Managing capture by jbert (Priest) on Feb 19, 2013 at 12:55 UTC
Yes, that would work. However, the drawbacks of this to me are: the check happens at runtime, not compiletime it requires each method taking a callback to implement the cycle check. that might be in 3rd party code and so require additional wrapping etc.	[reply]
Re^5: Managing capture by Anonymous Monk on Feb 19, 2013 at 13:22 UTC
... Yup, otoh, its cheap check (cheaper than universal competence ) and simpler to write than a pragma like autovivification -- have you looked at that thing? it walks the perl op-tree using c --- scary :)	[reply]
Re^3: Managing capture by Anonymous Monk on Feb 19, 2013 at 12:32 UTC
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 :)	[reply]
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]


Syntactic Confectionery Delight
	PerlMonks