use Perl

• Perl_(begin|check|init|end)av[] (Score:1)

  by jjore (6662)

  Your BEGIN, CHECK, INIT, and END blocks are present in the arrays Perl_(begin|check|init|end)av[]. You will need to set some variable like Perl_savebegin or somesuch to have anything to look at in Perl_beginav[].
  
  There might not be an array for UNITCHECK.
  
  Manip::END lets you muck with END blocks from perl-space. There's another one which does other blocks but I forget its name.
  • Re: (Score:2)

    by Ovid (2709)

    Aw, crap. My XS skills are week. However, the code itself doesn't look too difficult. I'll play with it. Right now it appears to work, but the code itself isn't too useful because of the 'naked' code reference:

    #!/usr/bin/perl -l
    
    use strict;
    use warnings;
    
    use Data::Dumper;
    use Manip::END;
    use Sub::Information;
    
    {
        package Foo;
    
        END { print 'end!' }
    }
    
    my $ends = Manip::END->new;
    print Dumper($ends);
    print $ends->[0]->();
    print inspect( $ends->[0] )->code;

    That produces:
    • Re: (Score:1)

      by chromatic (983)

      (Where does that '1' come from?)

      It's the return value of the print in the END block, isn't it?
      • Re: (Score:2)

        by Ovid (2709)

        D'oh!
• Naming (Score:1)

  by Aristotle (5147)

  What’s next? Devel::KickBack? Devel::R’and’R?

  :-)
  • Re: (Score:2)

    by Ovid (2709)

    Next is Devel::Procreate :)

    For the record, I hate the Devel::Recreate namespace. Suggestions welcome.
• Hmmm... (Score:1)

  by btilly (5037)

  Sounds like the wrong solution. There are lots of valid reasons that the module in memory might not match the one on disk. For instance someone could have created new functions by assigning to a typeglob or calling eval.

  For most cases, a module similar to Apache::Reload is right. Put in a check for which modules have changed on disk since you loaded them, then reload them.

  That doesn't help you in the case you have. But it is easy to create a module that redefines use and require. If you try to use
  • Re: (Score:2)

    by Ovid (2709)

    The above example is only one of many. If a module is not behaving the way I expect it to, particularly if "deep magic" is involved, than it's quite reasonable for me to want to see what's actually loaded in memory instead of what I think was loaded. Just a few areas where this would be helpful:

    • Auto-generated classes (such as the many auto-generated classes that ORM folks are fond of)
    • Method generators (Class::Delegator, Class::BuildMethods)
    • Moose!
    • Source filters (right now, debugging them is a
    • Re: (Score:1)

      by btilly (5037)

      I misunderstood. I thought you were proposing this module as a solution to help make sure that what was loaded is the same as the module on disk. You're not. What you're actually proposing doesn't have a simple solution.

      Carry on. :-)
      • Re: (Score:2)

        by Ovid (2709)

        Yes, I'm convinced that my module could only be used as a rough debugging guide. There are too many limitations that I cannot figure out how to get around, so it should probably only be a tool that developers can use if they read the docs carefully and really understand what its limitations are.
  • Re: (Score:1)

    by Aristotle (5147)

    Actually I don’t think it is a bad idea at all. You are right that this is not applicable in all cases in Perl because Perl was not designed to facilitate such usage. However, think Smalltalk, where a lot of “magic” is no problem because what you are browsing is the live in-memory representation of the program and so you see what it looks like after the meta-program parts have taken place.

    This is just the same thing for Perl. Of course it’s not going to work nearly as well in Perl