And I doubt that PadWalker can cause instabilities just by parsing the optree!

No? Try

perl -MPadWalker=peek_my 
-e"my $x = 42; sub { my $closed_over = $x; sub { peek_my 0 } }->()->()
+"
[download]

In any way I wouldn't suggest using code filters for error msgs in productive code...

Neither did I.

But then neither would I recommend the tracing of variables in production code.

The need for that is: a) a clear sign of inadequate testing; b) poor design.

Excepting Acts of God and Cosmic Rays, given the same values, code produces the same results. The only source of variability is IO.

And if this is a permanent feature of your logging or error handling, then the trivial extra investment to log:

20100327204831.321 file.pl(87): Received '...' from socket:0xdeadbeef
[download]

over

20100327204831.321 file.pl(87): $buf = '...';
[download]

The point is that noone, neither programmer nor user, is going to be able to draw any conclusions from "$buf = '...', without consulting the source. And with the file and line number, the variable that contains the value is obvious. Making it unnecessary information in the log.

For development time debugging, watching the values of variables change without reference to the source can give the programmer clues to his mistakes--out by one being the classic. And Smart::Comments is ideal for this.

But once you move into production, there is always a better identification for a value--more meaningful to both user and maintenance programmer alike--than the internal variable identifier.

You won't agree. And I won't argue the point further.