On 9/26/07, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> demerphq wrote:
> >> If that's the case, perhaps the docs for Terse could use stronger language.
> >> Right now it's a little obtuse.
> >>
> >> ·   $Data::Dumper::Terse  or  $OBJ−>Terse([NEWVAL])
> >>
> >> When set, Data::Dumper will emit single, non‐self‐referential
> >> values as atoms/terms rather than statements.  This means that the
> >> $VARn names will be avoided where possible, but be advised that
> >> such output may not always be parseable by "eval".
> >>
> >> Something like B<don't use this to serialize data in production!>
> >
> > I guess. To me thats obvious given the <but be advised that
> > such output may not always be parseable by "eval">
>
> Yeah, but you wrote a Dumper. :)
>
> Terse shows up in a bunch of examples, perhaps it should be removed from them?

Would something like the following patch be good in your opinion?

Untested because I don't have a compiler handy. :-(

Cheers,
yves


-- 
perl -Mre=debug -e "/just|another|perl|hacker/"
Only in Data-Dumper-2.121-Patched: Dumper.c
diff -wur Data-Dumper-2.121/Dumper.pm Data-Dumper-2.121-Patched/Dumper.pm
--- Data-Dumper-2.121/Dumper.pm	2003-08-24 07:12:00.000000000 +0200
+++ Data-Dumper-2.121-Patched/Dumper.pm	2007-09-26 10:13:15.984375000 +0200
@@ -9,7 +9,8 @@
 
 package Data::Dumper;
 
-$VERSION = '2.121';
+$VERSION = '2.121_999';
+$VERSION = eval $VERSION;
 
 #$| = 1;
 
@@ -22,7 +23,7 @@
 
 @ISA = qw(Exporter);
 @EXPORT = qw(Dumper);
[EMAIL PROTECTED] = qw(DumperX);
[EMAIL PROTECTED] = qw(DumperX DumpVar Dumpf Dumpp);
 
 XSLoader::load 'Data::Dumper';
 
@@ -492,6 +493,17 @@
 
 sub Dumpp { print Data::Dumper->Dump(@_) }
 
+sub DumpVar {
+    @_ != 1 and croak "DumpVar() expects exactly one argument";
+    return  "do{ my "
+          . Data::Dumper->new([EMAIL PROTECTED],['x'])
+                        ->Purity(1)
+                        ->Terse(0)
+                        ->Indent(0)
+                        ->Dump()
+          . '$x }'
+}
+
 #
 # reset the "seen" cache 
 #
@@ -675,11 +687,24 @@
     # OO usage
     $d = Data::Dumper->new([$foo, $bar], [qw(foo *ary)]);
        ...
+    # Debugging Grade Output
     print $d->Dump;
        ...
-    $d->Purity(1)->Terse(1)->Deepcopy(1);
+    # Persistance grade serialization
+    print $d->Purity(1)->Dump();
+
+    # Make a deep copy of the data
+    $d->Purity(1)->Deepcopy(1);
     eval $d->Dump;
 
+    # "Pretty output" UNSAFE for serialization
+    print $d->Terse(1)->Dump;
+
+    # Dump a single var for peristance purposes
+    use Data::Dumper qw(DumpVar);
+    $persist= DumpVar($original);
+    $restore= eval $persist;
+
 
 =head1 DESCRIPTION
 
@@ -719,6 +744,19 @@
 the C<Indent> flag.  See L<Configuration Variables or Methods> below 
 for details.
 
+=head2 Using Data::Dumper as a Data Persistance Mechanism
+
+It is unsafe to use Data::Dumper as a data persistance mechanism without setting
+Purity to 1 through either the global variable C<$Data::Dumper::Purity> or
+through the method call form Purity(1).
+
+If you wish to serialize a single variable safely it is recommended you use
+the DumpVar() subroutine, which will produce output that can be safely eval'ed
+back. For instance
+
+    use Data::Dumper qw(DumpVar);
+    my $persist= DumpVar($original);
+    my $restore= eval $persist;
 
 =head2 Methods
 
@@ -796,6 +834,16 @@
 output, where I<n> is a numeric suffix.  Will return a list of strings
 in a list context.
 
+=item DumpVar(I<VAR>)
+
+Returns the stringified version of a single var suitable for data peristance
+and restoration via eval.
+
+    my $persist= DumpVar($original);
+    # ...
+    my $restore= eval $persist
+        or die "Serialized data appears corrupt: [EMAIL PROTECTED]";
+
 =back
 
 =head2 Configuration Variables or Methods
@@ -871,7 +919,11 @@
 When set, Data::Dumper will emit single, non-self-referential values as
 atoms/terms rather than statements.  This means that the C<$VAR>I<n> names
 will be avoided where possible, but be advised that such output may not
-always be parseable by C<eval>.
+always be parseable by C<eval>. B<This means that using Terse(1) in production
+code as a data persistance mechansim is strongly discouraged.>
+
+See C<DumpVar> if you wish to have a var serialized such that it can be restored
+by capturing the result of evaling the serialized data.
 
 =item *
 
Only in Data-Dumper-2.121-Patched: Dumper.pm.bak
Only in Data-Dumper-2.121-Patched: Makefile
Only in Data-Dumper-2.121-Patched: blib
Only in Data-Dumper-2.121-Patched: pm_to_blib

Reply via email to