in reply to Inspection/Introspection

Unfortunately since there's no such thing as named parameters in Perl there's no real way to find out about a function's parameters either. (Update: That is, there is no introspective data structure where parameters could be read from; you have, as described below, to hook the function calls and dump the passed data to find out what's going on.)

A namespace's globals are stored in a hash that is named after it, with the double doublecolon; for example, %main::. To find out all the globals defined in package main, you could iterate over keys %main::, and query its type using f.ex ref $main::{some_global}.

A very useful module that comes to mind is Hook::WrapSub.

You could iterate over the keys in %SomeNamespace::, find which ones are subs, and wrap those in a function that logs debugging information, including the parameters in @_. You could also tie the global variables of the namespaces to wrapper classes that log their use.

It's going to be a fair bit of work though.

Makeshifts last the longest.

Replies are listed 'Best First'.
Re^2: Inspection/Introspection
by particle (Vicar) on Jun 22, 2002 at 22:03 UTC
    Unfortunately since there's no such thing as named parameters in Perl there's no real way to find out about a function's parameters either.
    true, and false!

    there are no named params in perl 5 (they're coming in perl 6.) you can find out about a function's parameters, though. use Devel::TraceSubs, my first cpan module (you'll have to install Hook::LexWrap first.) you specify namespaces in which you want to trace the subroutines, it reports in text or wrapped (read html) format. optionally, you can see the parameters passed to the subs. version 0.01 prints only scalars, so you won't see data inside references.

    you can see the stack depth for each call, and figure out how each piece of code relates to the rest.

    i'm working on changes (thanks to Jenda,) which i hope to put in version 0.02 (this weekend?) you'll be able to see params passed through Data::Dumper, and sub entry/exit timestamps. it will also fix some other bugs related to modules it's not allowed to trace (Carp, Data::Dumper, and any others i find.)

    oh, and i think you'll be better able to solve your overall problem by reading up on refactoring. Martin Fowler's book "Refactoring: Improving the Design of Existing Code", web site, buy it is a really good one. in case you don't get a chance to read it, i'll give you a few hints: don't refactor and add functionality at the same time, and take small steps. read the book, it's tremendous.

    ~Particle *accelerates*

      Sounds much like the approach I described. :) When I said there's no way to find out about a function's formal parameters, I meant that there's no introspective data structure anywhere that could provide this information, the way the namespace hashes provide information about the defined globals. Note I did point out you can wrap the traced subs with a debugger function that dumps the parameters to and results from them.

      Makeshifts last the longest.