«

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

On Jun 26, 12:49*am, Ben Morrow <b...@morrow.me.uk> 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

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.

On Jun 25, 7:49*pm, Ben Morrow <b...@morrow.me.uk> wrote:
> Quoth Nene <rodbas...@gmail.com>:
>
> > 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