As far as Data::Dumper, it's owned by the core, so you should not mess with the process.

If your explanation was a confusing to the P5P as it was here, I can imagine you've gotten very little feedback. {grin}

Secondly it would be good if you linked to the email with the patch that you sent to p5p. (There are several publically available websites that mirror that email list.)

That may clarify what you're asking for. It sounds like you want Data::Dumper to not try to dump objects that don't have a Freezer method. If this is really what you're asking for, you will never get it. A lot of people like being able to dump objects by default. If you're asking for something else you'll need to be clearer before anyone will act on it.

As for Class:AutoDB, I just glanced at the documentation. Without testing, it is a safe bet that you have serious bugs if the object winds up being destroyed during global destruction. With Perl 5.8 or better there is a hack that reduces how easily the bugs are hit. See Re (tilly) 1: using DESTROY to DBI disconnect and Re: Destructor Order for two posts where I mention this issue, and suggestions for how to avoid it. (Basically you have to do extra work to be sure that things will get cleaned up in an END block if they survived that long.) So even if you get nothing else out of this thread, you just got a pointer to a likely bug!

The object isn't destroyed at global destruction (though I certainly ran head-first into that issue during the first implementations). When the object is created, the Class::AutoDB::SmartProxy class is unshifted onto its ISA array. SmartProxy handles the object's persistence at its own destruction time (in a DESTROY block).
This seems to happen reliably, thoough I did implement a cache class for the dual purpose of speeding up in-memory access and acting as a container for flyweights (SmartProxy objects) to be destroyed all at once. Only the first purpose is being exercised since I prefer to have database I/O (during object destruction adn subsequent persistence) handled as needed.

Keep trying perl5-porters; sometimes people get busy and miss messages. You will generally get more comment on your patch if it is included in the body of your message, or an uncompressed attachment. Also try putting [PATCH] in your Subject.

The listed maintainer of the CPAN module is ilyam@cpan.org, but the change really needs to be accepted in the core before going in a cpan version.

Does Data::Dump::Streamer do what you need? You might consider it instead.

Getting your patch into Data::Dumper is fine and everything, but have you considered either subclassing Data::Dumper or implementing your specific requirements in a much less general module?

That would at least make it easier for your users to use your module, which is really the point I suspect.

yes, this is what I assumed to be the second best (right behind using the patched CPAN version) approach.

Its second best because I would have to keep up with DD bug fixes in my subclass. But I agree that its, probably better than distributing a patch (which is also tied to the current DD version).

  no warnings 'redefine';
  if ($Data::Dumper::VERSION < NEXT_VERSION) {
    *Data::Dumper::some_method = 
        sub {
           # replacement code here
        };
  }
[download]

The upside here is that only users of your module will see the new Data::Dumper behavior, and you can document it in your module. The downside is that if Data::Dumper doesn't get your patch by NEXT_VERSION then you'll need to change your module to take it working.

All that said, I think you should probably take a step back here. Are you sure you need to change Data::Dumper? It's an old and rather stable module. If it doesn't do what you want maybe you need to sub-class it or replace it with something more suited to your needs.

-sam

Either my version of Data::Dumper already has your patch or I'm missing something vital:

#Data/Dumper.pm 2.12 line 233-235
    if (my $freezer = $s->{freezer}) {
      $val->$freezer() if UNIVERSAL::can($val, $freezer);
    }
[download]

My apologies for the abbreviated explaination, I was more asking about procedure than code, but since there is interest ;)
The culprit is here:


@@ -395,10 +395,7 @@
      
     if ($realpack) { # we have a
blessed ref
       $out .= ', \'' . $realpack .
'\'' . ' )';
-      my $toaster = $s->{toaster};
-      if (UNIVERSAL::can($val,
$toaster)){
-        $out .= '->' .
$s->{toaster} . '()'  if $s->{toaster} ne '';
-      }
+      $out .= '->' . $s->{toaster}
. '()'  if $s->{toaster} ne '';
       $s->{apad} = $blesspad;
     }
     $s->{level}--;
[download]


Without the patch, if I set up an instance of Data::Dumper as such:
my $dumper = new Data::Dumper(undef,'thaw')-> Freezer('DUMPER_freeze')->Toaster('DUMPER_thaw');
and one or more of the serialized objects is frozen like such:
my $freeze=$dumper->Values($ref_to_some_object)->Dump;
All serialized output will be of the form:
bless(DATA, CLASS)->(DUMPER_thaw);
so when I attempt to reconstitute it (thaw it):
my $thaw; # 'thaw' is the handle that I told DD to use eval $freeze # sets thaw
DD calls the DUMPER_thaw method on the object, whether it had it or not. If it has it, fine, use it. Otherwise, DD should use its default thawing capabilities.
Currenlty it will die with:

WARNING(Freezer method call failed):
Can't locate object method "DUMPER_freeze" via package
"TestAutoDBOutside_1" at
/tools/lib/perl5/5.8.4/i686-linux-thread-multi/Data/Dumper.pm line
158.
...
Attempt to free temp codematurely: SV
0x83ee194 at
/tools/lib/perl5/5.8.4/i686-linux-thread-multi/Data/Dumper.pm line
501.
Scalars leaked: 1
[download]


which all look like warnings, but the object never gets thawed.
Here is the test wich I included with the patch that explains things more thoroughly (it should only pass after DD is patched):


package DD_test;
use lib qw(../blib/lib ../blib/arch);
use Data::Dumper;
use Test::More qw/no_plan/;

$Data::Dumper::Useperl = 1;
my $DUMPER=new
Data::Dumper([undef],['thaw'])->Purity(1)->Indent(1)->Freezer('DUMPER_
+freeze')->Toaster('DUMPER_thaw');
                                       
my $f = new freezable;
my $t = new unthawable;

$f->{_OTHER} = new unthawable;
$t->{_OTHER} = new freezable;
                                          
my ($thaw);
                                       
print "-" x 100, "\n";
print "Freezable\n";
print "-" x 100, "\n";
my $th = $DUMPER->Values([$f])->Dump;
#print Dumper $th;
eval $th; #sets $thaw
#print Dumper $thaw;
isa_ok($thaw,'freezable');
is($thaw->oid, 1);
isnt($thaw->can('DUMPER_thaw'),undef);
is($thaw->{_OTHER}->oid, 3);
is($thaw->{_OTHER}->can('DUMPER_thaw'),undef);
undef $thaw;
                                       
print "-" x 100, "\n";
print "Unfreezable\n";
print "-" x 100, "\n";
                                       
my $th2 = $DUMPER->Values([$t])->Dump;
#sets $thaw
#print Dumper $th2;
eval $th2; #sets $thaw
#print Dumper $thaw;
is($thaw->oid, 3);
is($thaw->can('DUMPER_thaw'),undef);
is($thaw->{_OTHER}->oid, 1);
isnt($thaw->{_OTHER}->can('DUMPER_thaw'),undef);

## freezable package
package freezable;
                                       
sub new {
  my($self)=@_;
  return bless {}, $self;
}
                                       
sub oid {
 return 1;
}
                                       
sub DUMPER_freeze {
  my($self)=@_;
  print ">>>
DUMPER_freeze ",$self->oid,"\n";
  $self->{_OID} = $self->oid;
  $self->{_CLASS} = ref $self;
  return $self;
}
                                       
sub DUMPER_thaw {
  my($self)=@_;
  print "<<< DUMPER_thaw

", $self->oid, "\n";
  return $self;
}
                                       
sub oid2object {
  shift @_ unless ref($_[0])=~/DBI::/;
  %__PACKAGE__::OID_2_OBJECT=shift @_
if @_;
  return \%$__PACKAGE__::OID_2_OBJECT;
}

## unthawable package (no DUMPER_freeze, DUMPER_thaw method)
package unthawable;
                                       
sub new {
  my($self)=@_;
  return bless
{_OID=>$self->oid,_CLASS=>$self}, $self;
}
                                       
sub oid {
 return 3;
}
[download]

I see. The problem is not with the existence of the Freezer method but the Toaster method, now I understand. This actually looks like a real bug to me. I don't think your code is entirelycorrect though. You call the UNIVERSAL::can() even if the Toaster is not specified. I think the whole change needed is the condition on the line that adds the toaster call:

    if ($realpack) { # we have a blessed ref
      $out .= ', \'' . $realpack . '\'' . ' )';
-      $out .= '->' . $s->{toaster} . '()'  if $s->{toaster} ne '';
+      $out .= '->' . $s->{toaster} . '()'
+        if $s->{toaster} ne '' and UNIVERSAL::can( $val, $s->{toaster
+});
      $s->{apad} = $blesspad;
    }
[download]

Update: The problem is that this tests for the Toaster method while the data is serialized/exported, not while it's deserialized/imported. Which might make a difference. With the original code as soon as the export was created with Toaster set to something you can get "notified" about all restored objects, all you have to do is to create a sub in UNIVERSAL package. With your (or mine) change your method only gets called for objects that had the Toaster method at the time of the export.

You could change Data::Dumper to generate something like this:

...
map( (UNIVERSAL::can( $_, 'Toaster') ? $_->Toaster() : $_),
  bless ( {}, 'Package::Name')
),
...
[download]

but I think the easiest solution is to define

sub UNIVERSAL::Toaster { $_[0] }
[download]

in your script/module and all classes that do not define their own Toaster will inherit this default one.

Jenda
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
   -- Rick Osborne