Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Re: Managing capture

by Anonymous Monk
on Feb 19, 2013 at 11:45 UTC ( #1019530=note: print w/ replies, xml ) Need Help??


in reply to Managing capture

Or do people resolve this pain in a different way?

No substitute for competence and mandatory destructors :)

So...is this madness? And has it already been implemented?

No, and maybe no.

See B::Concise, B::Lint, PadWalker, autobox::Closure::Attributes

update: >>>>>>>>>>sanity?!?!?!?!?!<<<<<<<<<<


Comment on Re: Managing capture
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.

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

        Yes, that would work. However, the drawbacks of this to me are:

        1. the check happens at runtime, not compiletime
        2. 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.
      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 :)

        > 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.

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

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1019530]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (12)
As of 2014-12-26 21:56 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (176 votes), past polls