Hi Tanktalus!

The reluctance to use PadWalker was merely based on information I could read about it in the source and Pod documentation of Data::Dumper::Simple. It says:

Note that if you strongly object to source filters, I've also released Data::Dumper::Names. It does what this module does by it uses PadWalker instead of a source filter. Unfortunately, it has a few limitations and is not as powerful as this module. Think of Data::Dumper::Names as a "proof of concept".

This module is an alternative to Data::Dumper::Simple. Many people like the aforementioned module but do not like the fact that it uses a source filter. In order to pull off the trick with this module, we use PadWalker. This introduces its own set of problems, not the least of which is that PadWalker uses undocumented features of the Perl internals and has an annoying tendency to break. Thus, if this module doesn't work on your machine you may have to go back to Data::Dumper::Simple.

Now, I tested PadWalker quickly today to check how it works for some simple cases. And based on these tests I have a gut feeling that it may not be as general solution as using PPI. Firstly, I noticed that it can only access lexical variable names in the argument list. This is currently a severe limitation since very often you want to print out package variables. On the other hand, a good thing about PadWalker seems to be that it can easily differentiate between calls like p $var and p func($var). (The p function here is the call to Data::Printer::p()). So it will understand that in the latter call $var is not the sought printed variable. This is more difficult with PPI, but it should be possible.

Having said that, if you want the full path name to the current file, just use __FILE__. And if you want the full path name to the file that just called you, just use (caller)1. As a bonus, caller will also give you the line number that you were called from.

Yes exactly, that linenumber information given by caller() was what I was trying to exploit! However, the problem of determining the absolute path of the filename still persists, since __FILE__ can be a relative pathname. I am curious why the Perl porters did not make __FILE__ always be an absolute pathname. I cannot see any benefits of populating it with a relative pathname :)

> Note that if you strongly object to source filters, I've also released Data::Dumper::Names. It does what this module does by it uses PadWalker instead of a source filter. Unfortunately, it has a few limitations and is not as powerful as this module. Think of Data::Dumper::Names as a "proof of concept".

Ovid didn't update this text for years, but last time I talked to him he was very confident about this being stable.

But please note that PadWalker has still limitations, like when being called from within an eval .

see PadWalker::var_name BUG?

Cheers Rolf
_{(addicted to the Perl Programming Language and ☆☆☆☆ :)
Je suis Charlie!}

Regarding benefits of non-absolute __FILE__. I suspect it is because the information requires consulting the file system, perhaps at length, to resolve links and such. Often unnecessary and always more expensive.