Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

Re^2: Managing capture

by jbert (Priest)
on Feb 19, 2013 at 11:51 UTC ( #1019531=note: print w/ replies, xml ) Need Help??


in reply to Re: Managing capture
in thread Managing capture

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


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

      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.

        ...

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

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

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

        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

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (11)
As of 2015-07-29 12:34 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The top three priorities of my open tasks are (in descending order of likelihood to be worked on) ...









    Results (263 votes), past polls