Well, yes and no. Data::Dumper (and friends) are meant to stringify data structures in a way that makes them still suitable for being eval'ed back in. That's really awesome, but poses a huge constraint over pretty-printers. Earlier this year, brian d foy talked about the amazing powers of Data::Dump, but it still suffers from those constraints. Same goes for the (also great) Data::Dump::Streamer.
Here's a quick visual comparison between the ever popular Data::Dumper and the new Data::Printer:
First thing you'll notice is the colored output, indexed arrays and a little extra regex information. But Data::Printer offers much more than that. How about debugging objects?
And what if your data is attached to others?
The idea behind Data::Printer is that most developers (at least to my experience) use such tools mostly just to see what's going on inside their variables and objects, not to serialize data in and out of Perl. So I decided to make a module that would focus on that: display Perl variables and objects on screen, properly formatted (to be inspected by a human). Data::Printer is somewhat similar to Ruby's "awesome_print", but I made sure to include more customization options and some neat features present in Perl's data dumpers.
For example, I called the printer function "p()" as it's nice and short and should steer clear of name collisions. But if you're so used to calling "Dumper()" in your code it just comes out naturally while you type, you can try this:
use Data::Printer alias => 'Dumper';
Dumper( %foo ); # there, problem solved!
Data::Printer comes with (I hope!) very sane defaults, so usually all you have to do is "use Data::Printer" (or even shorter: "use DDP") and start peeking at data structures with the exported "p()" function. But pretty is a matter of personal taste, and from colors to array indexes to the hash separator and their default values, you can customize just about anything!
Sounds neat, but I'm not gonna type all that every time!
And you shouldn't - which is why Data::Printer looks for a file called
.dataprinter in your home directory and lets you keep all your preferred settings right there, so you only have to worry about it once :-)Filters
There are times when you don't really wish to see an entire object's internals during your review, just that important piece of information that you're holding in it. Data::Printer also offers you the ability to easily add filters to override any kind of data display:
use Data::Printer filters => {
'DateTime' => sub { $_[0]->ymd },
'HTTP::Request' => sub { $_[0]->uri },
};
If your filters are too complex you can create them as a separate module and load them by name. You can even upload them to CPAN so others can benefit from it! In fact, Data::Printer already ships with some (hopefully useful) filters for the whole DateTime family of modules (not just DateTime, but also Time::Piece and friends), and some Database ones as well (currently DBI and DBIx::Class):
You can also make your classes Data::Printer-aware simply by adding a _data_printer() function to them. You don't have to add Data::Printer as a dependency at all, and it will use that function to filter your class by default instead of doing a regular dump.
In Short...
If you want to serialize/store/restore Perl data structures, this module will NOT help you, and you should try other solutions such as the Dumper/Dump family, Storable, JSON, or whatever you can find on CPAN.
But if you only care about seeing what's going on inside your data structures and objects, give Data::Printer a try! Oh, and if you're into REPLs, you can add it as your default dumper for Devel::REPL too =)
Code is on github. Comments, feature requests, bug reports and patches are welcome!
