On Sun, Feb 22, 2004 at 02:34:58PM -0500, Andrew Pimlott wrote:
> On Sat, Feb 21, 2004 at 03:42:40PM -0600, Dave Rolsky wrote:
> > I think the problem is that Data::Dumper has historically had two
> > orthogonal uses. One was serializing data structures for persistence, ala
> > Storable, and the other was for debugging.
> >
> > Nowadays, I'm guessing most people use Storable for the first, and so it's
> > probably used more for debugging. But just dumping the structure as is
> > may not be ideal for debugging.
>
> This dichotomy is unfortunate. It's quite nice to have a readable
> serialized format, when space is not important. However, you must use
> Data::Dumper _very_ carefully to get reliable serialization, and when I
> suggested that it be made easier, people said "Data::Dumper is for
> pretty-printing, use Storable". Meanwhile, Data::Dumper is much more
> verbose than a pretty-printer needs to be. So it's sort of stuck in
> no-man's land.
I'd support a patch to Data::Dumper that added (something like) a
$Data::Dumper::Stringify = ...
Where 0 (the default) means dig into objects the way it does now.
And 1 means if $obj->can('"') then dump the object as a string.
That seems simple, fast and effective.
An extra layer of the icing on the cake could be:
$Data::Dumper::Stringify = {
DEFAULT => 1, # or 0
$class_name => 0, # or 1
};
to control stringification style of individual classes.
(But that icing doesn't work well in the face of subclasses.)
An alternative/complementary approach would be to allow a callback
to be called for each newly encountered class during a Dump.
The return value would then control how Data::Dumper behaves
for instances of that class.
The callback can use $obj->isa($base_class) to control stringification
so that subclasses are also covered.
Tim.
p.s. CC'd to Ilya Martynov <[EMAIL PROTECTED]>, the current maintainer
