Looking at the documentation of Data::Dumper, I think you'd be best off by writing appropriate Freezer and Toaster subroutines, but there is $Data::Dumper::Bless which you can set to a subroutine name of your own choosing instead to load the target module:

#!perl
use 5.020;
use Data::Dumper; 
$Data::Dumper::Deparse=1;
$Data::Dumper::Bless="my_bless";
package Foo {};
say Dumper bless { name => "foo" } => "Foo";
__END__
$VAR1 = my_bless( {
                    'name' => 'foo'
                  }, 'Foo' );
[download]

On the receiving side, you can then implement my_bless as:

sub my_bless( $ref, $class ) {
    require $class;
    bless $ref => $class;
}
[download]

But again, implementing the appropriate Freezer and Toaster is much saner than using Data::Dumper and eval.

Yes, this. With the caveat that require $class won't work. Use Module::Runtime or eval "require $class". (I know eval on untrusted input is bad, but you're already doing eval on the Data::Dumper output, so it doesn't make things worse in this case.)

Hire me at Toby Ink Ltd or Join my OnlyFans

If you think that Perl has not a most generic approach to objects, you'd probably haven't looked into the "huh, this is possible?" corner enough. Take a look at this:

#!/usr/bin/env perl

use strict;
use warnings;

use Data::Dumper;

# Turn a scalar into a blessed object
my $foo = 'THIS IS A SCALAR';
my $bar = [qw(THIS IS AN ARRAY)];
my $baz = {'This' => 'Is', 'A' => 'Hash'};

my $scalarobject = bless \$foo, 'This::Is::A::Dummy::Object';
my $arrayobject = bless $bar, 'This::Is::A::Dummy::Object';
my $hashobject = bless $baz, 'This::Is::A::Dummy::Object';

{
    # Force the This::Is::A::Dummy::Object class to have a print metho
+d that stringifies itself ;-)
    no strict 'refs';
    *{'This::Is::A::Dummy::Object::stringify'} = sub{ my ($self) = @_;
+ print Dumper($self); };
}

$scalarobject->stringify();
$arrayobject->stringify();
$hashobject->stringify();
[download]

This blesses a scalar, an array and a hash with a class that we didn't even create beforehand. AFTER it does that, it modifies the class and adds a "stringify" method, which in turn modifies all the objects of that class. Then we stringify all objects with this newly created method. Result:

$VAR1 = bless( do{\(my $o = 'THIS IS A SCALAR')}, 'This::Is::A::Dummy:
+:Object' );
$VAR1 = bless( [
                 'THIS',
                 'IS',
                 'AN',
                 'ARRAY'
               ], 'This::Is::A::Dummy::Object' );
$VAR1 = bless( {
                 'A' => 'Hash',
                 'This' => 'Is'
               }, 'This::Is::A::Dummy::Object' );
[download]

If that is not generic and flexible, i don't know what is.

SCNR

Of course you could complain that subs could have been added dynamically outside the module.

So one could think about dumping the STASH ...

  DB<26> sub BLA::foo { print "BLA::foo"}

  DB<27> use Data::Dumper

  DB<28> p Dumper \%BLA::
$VAR1 = {
          'foo' => *BLA::foo,
          'AUTOLOAD' => *BLA::AUTOLOAD
        };
[download]

... alas, Data::Dumper won't serialize the sub's body.

Other serializers allow B::Deparse to hook in ( Data::Dump probably, IIRC? ) , but this source representation is not 100% reliable.

And that's where - in my humble opinion - your interesting idea hits a wall.

As long as one can't reliably serialize the code of the subs of a class, one will need to resort to add the class' code manually.°

While it's possible to introspect in which file and line a sub was defined, this will only help if it was static source and not a dynamically built eval $SOURCE .

In short: Serializing the methods of a class is very hard in Perl if it has to be fail proof.

(I was too eager to meditate and too lazy to search, you may want check if CPAN already offers a solution for that :)

°) On a side note: JS has a method .toSource() for such introspection, which unfortunately lacks in Perl.

update

Anyway ... I'd be interested to know the use case you see. Packages are after all _global_, so resurrecting them might lead to so heavy side effects, that manual interference is needed anyway.

To expand a bit, the configuration setting is $Data::Dumper::Deparse to make Data::Dumper also dump the (deparsed) source code of code references. But as LanX already said, the source representation is functionally mostly identical but will not necessarily represent the original code identically.

The interesting part is once you have subroutines closing over common variables, like for example getters/setters:

my $name = 'foo';
my $package = {
    getter => sub ( $self ) { return $self->{$name} },
    setter => sub ( $self, $value ) { return $self->{$name} = $value }
+,
}
[download]

You need to dump these at once so that Data::Dumper dumps the reference to the common variable $name as a single variable. This happens whenever your class has autogenerated methods (like with Moo, Moose etc.).

Depending on how much control you have over the source code of the class to be dumped, this can make things far more hairy than you want.

OK if you only want to be warned if the package doesn't exist, you can also override bless locally inside a package to do the check for you.

please note that blessing will autovivify the class, i.e. the package TST1:: will "exist".

use strict;
use warnings;
use Data::Dumper;

my $obj = bless {}, "TST1";
my $str1 = Dumper $obj;

my $str2 = q($VAR1 = bless( {}, 'TST2' ););




package Bless::Safe;


use subs qw/bless/;

sub bless ($;$) {
    my ($obj,$class) = @_;
    die "Can't bless into non-existent Package $class"
      unless exists $main::{"${class}::"};
}


our $VAR1;

eval($str1) or $@ && die $@;                     # OK
eval($str2) or $@ && die $@;                     # FAILS
[download]

Can't bless into non-existent Package TST2 at d:/tmp/pm/override_bless.pl line 21.

HTH! :)

updates

Yeah, I already saw issues with attempting to really package the class as part of the stringification (all sorts of issues, many already mentioned here, both in general and in my particular use); I was just a little surprised not to be warned that I'd neglected to use the package.

I was thinking about adding a new function call to do eval-with-bless-checking, hadn't realized I could actually overload bless to verify the package. I don't do any blessing without packages that I remember in this code, so that might be a clean way to fix that.

At least I've learned something new (didn't realize I could override bless!). I shouldn't be surprised, at this point there's not all that much I can't override in Perl.

> At least I've learned something new (didn't realize I could override bless!). I shouldn't be surprised, at this point there's not all that much I can't override in Perl.

Please note that it's not global but "only" on package basis, which is a good thing. Better don't try this in main.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

I propose that the real problem is using Data::Dumper as something else as a data visualizer.

Possibly Dumper is the wrong tool here, yeah.

I looked at JSON and XML, and it looked to me like the overhead was unreasonable for this use, and that I had to use options that made the generated "standard" representation non-standard to do what I needed (which was to convey Perl objects that I created specifically for communicating between these two programs, between these two programs). And it's a pretty personal specialized application, I don't see it really ever being used outside my network. So this looked like the quickest and cleanest way to get it running, the big downside being that it's solidly perl-specific. Which doesn't bother me a bit.

I was looking for how to format the information (some header information followed by a list of filenames, repeated multiple times) and parse it to separate the "finding the files to display" function from the "generate the PDF showing the image thumbnails and some information" function, and I realized that inventing my own format was stupid and I should use something standard, but when I looked at the obvious "standard" choices they required generating and parsing code to get to what I needed, and I realized that Dumper didn't. In this limited use I'm not scared of evaling the input (which I produced myself and stored in a file in my own directory), and there's nothing approaching the complexity of circular references or anything, nor likely to ever be (just doesn't fit the data model).

I looked at JSON and XML

Those are good^* formats for exchanging generic data with other applications - especially so when the other applications are not (necessarily) Perl.

If you are intending to exchange data between only Perl applications then something like Storable (or Sereal) might be more appropriate.

^* for some definitions of "good" ;-)

---

🦛