Taking a part a Perl Object.

Discussion in 'Perl Misc' started by Nene, Jun 26, 2012.

  1. Nene

    Nene Guest

    Hi,
    I've been tasked to learn the behavior of a complicated homegrown Perl
    module.

    Are there any resources on how to to take a part a perl module, in
    particular the 'new' object?

    I want to learn the guts of the 'new' object, would the perl debugger
    be a good start?

    Nene
     
    Nene, Jun 26, 2012
    #1
    1. Advertising

  2. Nene

    Marc Girod Guest

    On Jun 26, 12:49 am, Ben Morrow <> wrote:

    > Personally I don't find the Perl debugger terribly useful. However, it
    > may be more so when trying to decipher code you don't yet understand.


    On the contrary, I use the debugger a lot. I find it useful to place
    breakpoints, inspect the trace and the values of the variables.
    Possibly use only the 'action' function (usually print, but sometimes
    modify).

    Marc
     
    Marc Girod, Jun 26, 2012
    #2
    1. Advertising

  3. Ben Morrow <> writes:
    > Quoth Nene <>:


    [...]

    >> I want to learn the guts of the 'new' object, would the perl debugger
    >> be a good start?

    >
    > Reading the source, carefully, would be a good start. Once you think you
    > have an idea how the module works, write little programs that call a
    > function or two, and see if they do what you expected: forming theories
    > which you can then test is a much more efficient way of finding things
    > out than trying things aimlessly. If necessary you can insert 'warn'
    > statements (or something else appropriate) here and there to print out
    > important variables, and to see where the control goes.


    I suggest the same thing: If you don't understand the actual control
    flow, try to catch it with subsequently more specific "does it pass
    here?" ad hoc diagnostics, possibly printing other values of interest
    while having the source code loaded in a reasonable editor.

    In my experience, that's a lot faster and more convenient than trying
    to single-step through large bodies of code. You never want to know
    everything. It also works in situations where 'stop the world to
    inspect its state' isn't possible.
     
    Rainer Weikusat, Jun 26, 2012
    #3
  4. Nene

    Nene Guest

    On Jun 25, 7:49 pm, Ben Morrow <> wrote:
    > Quoth Nene <>:
    >
    > > I've been tasked to learn the behavior of a complicated homegrown Perl
    > > module.

    >
    > I suppose it's futile to ask if the module is documented or commented
    > properly?


    It is documented but very vaguely.

    > If there is a test suite, so you can get some idea of how the
    > author intended it to be used?


    Yes, the author has test scripts which I made copies of and made them
    smaller tests. Once I understand the rudiments
    of the module ( a REST API, btw ). I will use his personal tests.
    > Do you at least have examples of programs
    > which successfully use the module?
    >
    > > Are there any resources on how to to take a part a perl module, in
    > > particular the 'new' object?

    >
    > 'new' is usually a method.


    Thank you clarifying that. What I have learned from the new method,
    correct me if I am wrong, that it is the vehicle to obtain
    the data required for the purpose of the module and the methods are
    there to do whatever you want with the data.
    >
    > > I want to learn the guts of the 'new' object, would the perl debugger
    > > be a good start?

    >
    > Reading the source, carefully, would be a good start. Once you think you
    > have an idea how the module works, write little programs that call a
    > function or two, and see if they do what you expected: forming theories
    > which you can then test is a much more efficient way of finding things
    > out than trying things aimlessly. If necessary you can insert 'warn'
    > statements (or something else appropriate) here and there to print out
    > important variables, and to see where the control goes.


    Thank you so much for this advice. I have inserted print statements
    all over the place and what I have learned that
    90% of all the data are obtained through hash references.

    >
    > Write things down as you go, so you don't forget them. If there isn't
    > any documentation, it would be a good idea to start writing it:


    I made a copy of the pm file with the print statements and added
    comments to the file, this file will be my reference file.
    Every time I fire up the tests, it will print comments, sort of like a
    review each time I use it.

    > exercise should help you form a clearer picture of what the code is
    > trying to accomplish, and how. Add comments to any bit of code that are
    > particularly obscure.
    >
    > Personally I don't find the Perl debugger terribly useful. However, it
    > may be more so when trying to decipher code you don't yet understand.
    >
    > Ben
     
    Nene, Jun 26, 2012
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jack
    Replies:
    8
    Views:
    289
  2. Jim Cain
    Replies:
    1
    Views:
    211
    Yukihiro Matsumoto
    Jul 18, 2003
  3. Saeed
    Replies:
    1
    Views:
    185
    Lukas Mai
    Jul 10, 2004
  4. Andrew Hamm

    Solaris taking over Perl ownership

    Andrew Hamm, Nov 5, 2004, in forum: Perl Misc
    Replies:
    29
    Views:
    278
    Matt Garrish
    Dec 14, 2004
  5. Replies:
    1
    Views:
    106
    Mirco Wahab
    Jul 15, 2008
Loading...

Share This Page