in reply to RFC: Data::Dumper::Simple

To be honest I shy away from anything that relies on Filter::*.

I don't see it as particularly necessary here either, as to me, the greatest annoyance has always seemed to be the fact that named variable output requires passing two parallel arrays — rather than, as would seem more natural, hash-like named parameters. Something like this would suffice for me:

warn Data::Dumper->Dump( foo => $foo, this => \%this, array => \@array, that => \%that, );

This also makes the subtle typo you demonstrated much less likely.

(Assume that you are allowed to say '$foo' => $foo where you need the control.)

I am guessing this is all because whoever wrote Data::Dumper wanted the Dump() function to more-or-less DWIM, so that you wouldn't have to remember to call different functions for named or anonymous output. That could easily be achieved as well — Dump() could expect exactly one array- or hash-ref for anonymous or named output, respectively. This gives

warn Dump { foo => $foo, this => \%this, array => \@array, that => \%that, }; #vs warn Dump [ $foo, \%this, \@array, \%that ];

The price is, of course, that you have to use the appropriate set of delimiters.

Another thing that bugs me about Data::Dumper is the OO interface. The constructor takes no options, you have to set them all with one mutator call each. I'd much prefer the former:

my $dumper = Data::Dumper->new( purity => 1, terse => 1, deepcopy => 1 + ); warn $dumper->Dump( [ $foo, \%this, \@array, \%that ] );

Or something along these lines. There are numerous problems with my propositions here; I've never entirely thought this all through. All I'm really saying is that Data::Dumper really has a pretty awful interface, and that it should be possible to sanitize it and keep it DWIMmish without resorting to filters.

Makeshifts last the longest.

Replies are listed 'Best First'.
Re^2: RFC: Data::Dumper::Simple
by Ovid (Cardinal) on Jul 31, 2004 at 19:43 UTC

    Generally I would agree with you regarding using a source filter. It certainly isn't my first choice. However, it works in this case because this code is merely a very useful aid in quick debugging. It is not intended to be used for any sort of production work. As such, your interface would be good for a new Data::Dumper interface, but it does not satisfy my "quick debugging" need.

    warn Dump { foo => $foo, this => \%this, array => \@array, that => \%that, }; # versus Dumper($foo, %this, @array, %that);

    I certainly know which one I'd rather type :)

    Side note: it's on it's way to the CPAN (with a version number that I need to fix -- darn it!), but in the interim, you download it from my site and tell me how buggy it is.


    New address of my CGI Course.

      Maybe there's a way to fugde it with PadWalker or something similar, instead.

      Makeshifts last the longest.

        OK. That's pretty darned funny. PadWalker was my first attempt :) However, I wound up with some very strange bugs with PadWalker while I was holding aliases to variables in an outer lexical scope. It was very weird. Do you really prefer mucking around in the scratchpads better than a source filter?


        New address of my CGI Course.