-- Randal L. Schwartz, Perl hacker

Well, I dont support Dumper style variable naming, I do a Dump style do{} output instead. But heres your two cases. From what I can tell they come out correctly. Let me know if they are wrong.

UPDATE
Doh. I shouldhave read your bugreport more carefully. Obviously both of these are incorrect in the respect that you mention. But i'm pretty sure that I can resolve that. Ill let you know.

Oh and thanks, I've been meaning to get the Dumper test cases and run them through BFDump, but keep forgetting. So now that I've been reminded the download is running... ;-)

use Data::BFDump qw(BFDump);

my @dogs = ( 'Fido', 'Wags' );
my %kennel = (
  First => \$dogs[0],
  Second =>  \$dogs[1],
);
$dogs[2] = \%kennel;
my $mutts = \%kennel;

print "BFDump(\\\@dogs, \\\%kennel, \$mutts);\n";
print BFDump(\@dogs, \%kennel, $mutts),"\n\n";
print "BFDump(\\\%kennel, \\\@dogs, \$mutts);\n";
print BFDump(\%kennel, \@dogs, $mutts),"\n";

__END__
BFDump(\@dogs, \%kennel, $mutts);
do {
    my $RT_ARRAY = [
                     'Fido',
                     'Wags',
                     {}
                   ];
    my $RT_HASH  = {
                     First  => \do { my $v = 'Fido' },
                     Second => \do { my $v = 'Wags' }
                   };
    $RT_ARRAY->[2] = $RT_HASH;
    ( $RT_ARRAY, $RT_HASH, $RT_HASH )
}

BFDump(\%kennel, \@dogs, $mutts);
do {
    my $RT_HASH  = {
                     First  => \do { my $v = 'Fido' },
                     Second => \do { my $v = 'Wags' }
                   };
    my $RT_ARRAY = [
                     'Fido',
                     'Wags',
                     $RT_HASH
                   ];
    ( $RT_HASH, $RT_ARRAY, $RT_HASH )
}
[download]

Oh and if anyone is wondering what the RT means in the variable names, it stands for root.

Yves / DeMerphq
---
Writing a good benchmark isnt as easy as it might look.

Do you have switch and output compatability modes to plug into code that already uses DD or DD? *hint* *hint*

PS:

Oh and if anyone is wondering what the RT means in the variable names, it stands for root.

Do you have switch and output compatability modes to plug into code that already uses DD or DD? *hint* *hint*

Well, as you can see from my current example I support the Data::Dump style interface and not the Data::Dumper interface. However Im sure I can include a wrapper that emulates Data::Dumper functionality.

Although I have to say that my intention is not so much to create a drop in replacement for either (although it should be up to job) but rather a development tool for trying to visualize and analyze data structures. Part of the reason that I take this perspective is that many trade-off decisions have been made in favor of analytical and presentational flexibility and utility and not to speed or memory overhead type concerns.

So if you have to serialize a few million data structures then Data::BFDump is probably not the place to go (unless of course you are dumping structures that would be affected by the bugs I mentioned earlier.) OTOH if you are trying to figure out what data structure is being used by a new module, or why you keep getting weird results with that funky data structure you are developing then my tool will probably be exactly what you want to use.

Then waste the two bytes and call it root. :)

Honest I tried it. Trouble is that there are two prefixes used "BF" and "RT", and then the vars can be numbered as well so if I use ROOT explicitly in some situations the variable names get quite long indeed...

Maybe Ill make it an option though. Compromise eh? :-)

Yves / DeMerphq
---
Writing a good benchmark isnt as easy as it might look.

   MeowChow                                   
               s aamecha.s a..a\u$&owag.print

Well, Im familiar enough with Data::Denter to know that it doesnt meat at least one my needs.

One key issue for me is not that the dumper chosen can "handle" cyclic structures, but that it deals with them in a reasonable way.

Consider a situation where we have an array of objects, perhaps representing people. Now each object contains an array of references to some or all of the other objects, perhaps representing some kind of relationship between them. Now if I use depth first dumper to dump this array of objects, the dumper will dump the first object and then follow the references dumping each object (which are not children!) as if they were children of the first object. Almost inevitably this will result in a large chunk of the top level array containing references into the tree of parent and children objects. This is not what I want.

What I would rather see is an array containing objects which contain an array with references to the other objects. The fact that an object is in the top level array means that it should be first mentioned in the context of this array, not as a child of another object.

Some other functionality that ive built in (and wanted)includes "slicing" out a many mentioned object and declaring it first so that instead of having many "fix" statements at the end we can simply have this object mentioned multiple times. In fact ive got this implemented in such a way that the user can specify how many times an object needs to be referenced before it gets split out.

In fact is precisely the "splitting" function that made me fail merlyns test case. I need to resolve this in the next few days, but once I do I will be able to handle both of merlyns tests.

Oh and did I mention that I convert code refs to code when I dump?

Yves / DeMerphq
---
Writing a good benchmark isnt as easy as it might look.

Oh and did I mention that I convert code refs to code when I dump?

I sometimes read the newspaper. ;-)

--
John.