Re: Managing capture

Replies are listed 'Best First'.
Re^2: Managing capture by jbert (Priest) on Feb 19, 2013 at 11:51 UTC
> No substitute for competence and mandatory destructors :) 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.	[reply]
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
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
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
Re^2: Managing capture by Anonymous Monk on Feb 19, 2013 at 12:07 UTC
forget about sanity, the "closure" it deals with is fatal warning, see perllexwarn, it warns about odd cases of closure where closure won't happen , nothing to do with disabling closures intentionally	[reply]
Re^2: Managing capture by Anonymous Monk on Feb 19, 2013 at 14:30 UTC
Another implementation idea is B::Xref, this shows up as Subroutine foo Package (lexical) $other i5 $self i4, 11 Package ? ?? &11 under subroutine foo, anonymous package, referencing $self Could ask the B::Lint folks for an implementation :)	[reply]


go ahead... be a heretic
	PerlMonks