Data::Dumper::Names man page on Pidora

Man page or keyword search:  
man Server   31170 pages
apropos Keyword Search (all sections)
Output format
Pidora logo
[printable version]

Data::Dumper::Names(3)User Contributed Perl DocumentatioData::Dumper::Names(3)

NAME
       Data::Dumper::Names - Dump variables with names (no source filter)

VERSION
       Version 0.03

SYNOPSIS
	   use Data::Dumper::Names;

	   my $foo = 3;
	   my @bar = qw/this that/;
	   warn Dumper($foo, \@bar);
	   __END__
	   output:

	   $foo = 3;
	   @bar = (
	       'this',
	       'that'
	   );

EXPORT
       Like Data::Dumper, this module automatically exports "Dumper()" unless
       a null import list is explicitly stated.

       This module should be considered ALPHA.

FUNCTIONS
   Dumper
	warn Dumper($foo, \@bar);

       "Dumper" returns a string like "Dumper" but the variable names are
       prefixed for you.  Unlike Data::Dumper::Simple, arrays and hashes must
       be passed by reference.

CAVEATS
   PadWalker
       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.

   References
       Arrays and hashes, unlike in Data::Dumper::Simple, must be passed by
       reference.  Unfortunately, this causes a problem:

	my $foo = \@array;
	warn Dumper( $foo, \@array );

       Because of how pads work, there is no easy way to disambiguate between
       these two variables.  Thus, "Dumper" may identify them as $foo or it
       may identify them as @array.  If it misidentifies them, it should at
       least do so consistently for the individual call to "Dumper".  (For
       Perl 5.8 and after, subsequent calls to "Dumper" may have different
       results in the above case.  This is because of how Perl handles hash
       ordering).

   Call stack level
       You generally will call things with this:

	warn Dumper($foo, $bar, \@baz);

       However, you might be refactoring code and want to shove that into a
       subroutine somewhere.  In that case, you'll need to set (via "local"!),
       the $Data::Dumper::Names::UpLevel variable.  It defaults to one, but
       you might set it to a higher level, depending on how high up the call
       stack those variables are really located:

	sub show {
	    return unless $ENV{VERBOSE};
	    local $Data::Dumper::Names::UpLevel = 2;
	    warn Dumper(@_);
	}

       Note that if you fail to use "local", subsequent calls to "Dumper" may
       be looking at the wrong call stack level.

   Unknown Variables
       The easiest way to have things "just work" is to make sure that you can
       see the name of the variable in the "Dumper" call:

	warn Dumper($foo, \@bar); # good
	warn Dumper($_);	  # probably will get output like $VAR1 = ...
	warn Dumper($bar[2]);	  # probably will get output like $VAR1 = ...

       Usually the output from Dumper will be something like this:

	$foo = 3;
	@bar = (
	   'this',
	   'that'
	);

       However, sometimes a $VAR1 or $VAR2 will creep in there.	 This happens
       if pass in anything but a named variable.  For example:

	warn Dumper( $bar[2] ); # $VAR1 = ... can't figure out the name

       We probably won't be able to figure out the name of the variable
       directly unless we took the time to walk all data structures in scope
       at the time "Dumper" is called.	This is an expensive proposition, so
       we don't do that.  It's possible we will be able to figure out that
       name, but only if the variable was assigned its value from a reference
       to a named variable.

	$bar[2] = \%foo;
	warn Dumper( $bar[2] );

       "Dumper", in the above example, will identify that variable as being
       %foo.  That could be confusing if those lines are far apart.

	foreach ( @customer ) {
	   print Dumper( $_ );
	}

       It should go without saying that the above will also probably not be
       able to name the variables.

AUTHOR
       Curtis "Ovid" Poe, "<ovid@cpan.org>"

BUGS
       Please report any bugs or feature requests to
       "bug-data-dumper-names@rt.cpan.org", or through the web interface at
       http://rt.cpan.org/NoAuth/ReportBug.html?Queue=Data-Dumper-Names
       <http://rt.cpan.org/NoAuth/ReportBug.html?Queue=Data-Dumper-Names>.  I
       will be notified, and then you'll automatically be notified of progress
       on your bug as I make changes.

ACKNOWLEDGEMENTS
       See Data::Dumper and Data::Dumper::Simple.

       Thanks to demerphq (Yves Orton) for finding a bug in how some variable
       names are reported.  See Changes for details.

COPYRIGHT & LICENSE
       Copyright 2005 Curtis "Ovid" Poe, all rights reserved.

       This program is free software; you can redistribute it and/or modify it
       under the same terms as Perl itself.

perl v5.14.0			  2011-06-19		Data::Dumper::Names(3)
[top]

List of man pages available for Pidora

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net