Mailing List Archive

The Dumper as posted doesn't deal with quoted quotes or backslashes.
Here's a patch.

I've also made it a lot more cautious about what sort of numbers it
doesn't quote, since the posted version can lose precision if a long
number is held as a string.

Depending on what you do with the text, having literal \000 characters
in the strings is also a little dicy - one edit and they'll be mangled,
if you use the wrong editor. I think that double-quoted string have to
be the way to go here. Am I right in saying that the only double-quoted
magic chars are ["\@$] ?

I think I'd prefer a treatment of CODE refs that actually provoked a
warning on restoring. Treatment of these is more difficult than it might
appear, since a CODE ref can be a closure. Closures defined by the
same block share (writable) instances of any lexical-scope variables
inherited, so a reconstruction would have to deal with this case.

Ian

*** Dumper-1.2.pm.orig Thu Nov 23 11:31:25 1995
--- Dumper-1.2.pm Thu Nov 23 12:04:55 1995
***************
*** 272,279 ****
}
else { # simple scalar
! if ($val =~ /^[+-]?\d+\.?[\d]*$/o || ref(\$val) eq 'GLOB') {
$out .= $val; # if number or glob
}
else {
$out .= '\'' . $val . '\''; # if string
}
--- 272,280 ----
}
else { # simple scalar
! if ($val =~ /^-?\d{1,8}$/o || ref(\$val) eq 'GLOB') {
$out .= $val; # if number or glob
}
else {
+ $val =~ s/[\\']/\\$&/g;
$out .= '\'' . $val . '\''; # if string
}

On Thu, 23 Nov 1995 12:29:12 GMT, Ian Phillipps wrote:
>The Dumper as posted doesn't deal with quoted quotes or backslashes.
>Here's a patch.

Thanks.

Funny how I fixed this exact same thing yesterday and
posted ver. 1.22 on CPAN. Get the latest version.

>I've also made it a lot more cautious about what sort of numbers it
>doesn't quote, since the posted version can lose precision if a long
>number is held as a string.
>

Ok.

>Depending on what you do with the text, having literal \000 characters
>in the strings is also a little dicy - one edit and they'll be mangled,
>if you use the wrong editor. I think that double-quoted string have to
>be the way to go here. Am I right in saying that the only double-quoted
>magic chars are ["\@$] ?

Lionel Cons also suggested having double quoted chars with at least \t and
\n instead of the literals in private mail. My take on this was that it can
get cumbersome to quote all of the ["$@\\t\n\0xx] things and slow down
stringification. I think I will make it optional to do this.

>
>I think I'd prefer a treatment of CODE refs that actually provoked a
>warning on restoring. Treatment of these is more difficult than it might
>appear, since a CODE ref can be a closure. Closures defined by the
>same block share (writable) instances of any lexical-scope variables
>inherited, so a reconstruction would have to deal with this case.
>

I can add a warning, but like you say, a more complete treatment of coderefs
is not going to happen anytime soon (at least, not until there's internal
support for it in perl).

The feedback is very much appreciated, thanks.

- Sarathy.
gsar@engin.umich.edu

Gurusamy Sarathy <gsar@engin.umich.edu> wrote:

> Lionel Cons also suggested having double quoted chars with at least \t and
> \n instead of the literals in private mail. My take on this was that it can
> get cumbersome to quote all of the ["$@\\t\n\0xx] things and slow down
> stringification. I think I will make it optional to do this.

Good idea, but another feeping creature, of course.
High on the list for escaping are both \r and \n, since these are the
common characters (with \t and ascii space) most likely to be mangled by
transmission or manipulation as text (e.g. if sent as email).

There's also a case for letting packages control Dumpification of their
own blessed objects - as they do, willy-nilly, if $OVERLOAD{"''"} is
defined.

Wacky idea - comments welcome:

How about a sending a Data_Dumper message to any blessed object.
You could even make the Dumper module define &UNIVERSAL::Data_Dumper to
be quoted-stringification, which would simplify things.

> >I think I'd prefer a treatment of CODE refs that actually provoked a
> >warning on restoring.
> I can add a warning, but like you say, a more complete treatment of coderefs
> is not going to happen anytime soon (at least, not until there's internal
> support for it in perl).

Since writing, I've been wondering: how difficult would it be to track
down code refs that appear in some symbol table? Or maybe those that
take the trouble to register themselves:

[quick hack - an OO version might be different]
sub register_code {
my ($caller) = caller;
for(@_) {
$_code_register{ \&{"$caller::$_"} } = "$caller::$_";
}
}

Ian

On Thu, 23 Nov 1995 18:39:43 GMT, Ian Phillipps wrote:
>Wacky idea - comments welcome:
>
>How about a sending a Data_Dumper message to any blessed object.
>You could even make the Dumper module define &UNIVERSAL::Data_Dumper to
>be quoted-stringification, which would simplify things.
>

UNIVERSAL::Data_Dumper may not even be needed, since it is trivial to check
for defined(&Package::Data_Dumper) and call it if it exists, before
attempting stringification. In fact, this will be another freature :-) I'll
make the method name user definable, so any persistance implementation can
use Data::Dumper to do its stuff.

>
>Since writing, I've been wondering: how difficult would it be to track
>down code refs that appear in some symbol table? Or maybe those that
>take the trouble to register themselves:
>

I have vague plans on these lines, and this really belongs in a separate
module. One that will marry Data::Dumper and Devel::Symdump, and resolve the
names of supplied references and dump them. Fairly simple to do actually
(since most of the needed functionality is already a part of the two
modules). A debugger will benefit greatly with this new module.

>
>Ian
>

- Sarathy.
gsar@engin.umich.edu

On Fri, 24 Nov 1995 08:32:19 GMT, Nick Ing-Simmons wrote:
>In <199511231930.OAA29119@aatma.engin.umich.edu>
>On Thu, 23 Nov 1995 14:30:41 -0500
>Gurusamy Sarathy <gsar@engin.umich.edu> writes:
>>
>>UNIVERSAL::Data_Dumper may not even be needed, since it is trivial to check
>>for defined(&Package::Data_Dumper)
>
>Which means you don't use Inheritance.
>

As much as I hate UNIVERSAL::Pollution, there seems to be no way
out of that quandary, is there?

- Sarathy.
gsar@engin.umich.edu

On Fri, 24 Nov 1995 09:03:03 +0100, Tom Christiansen wrote:
>Now, how might one properly dump @GF? Although this is an certainly an
>obvious problem here in the previous code, such troubles can also
>easily arise in simpler scenarios. The problem is getting the
>no-longer-findable lexicals properly deeply bound in the closure. Perl
>of course does this, but unless and until you've internal compiler
>support for such things, and maybe not even then, I don't think it
>feasible.
>

Well, for one thing, we can't tell lexicals apart from package globals.
Until we do, and until the cv's pad is accessible in some form,
storing closures properly is completely beyond reach.

I think a halfway decent solution (without the closures gordian knot) is to
make the parser cache-on-demand the string form of the sub. You can still
do some of this now by jumping through the DB:: package hoops, but it
deserves better.

- Sarathy.
gsar@engin.umich.edu

In <199511231930.OAA29119@aatma.engin.umich.edu>
On Thu, 23 Nov 1995 14:30:41 -0500
Gurusamy Sarathy <gsar@engin.umich.edu> writes:
>
>UNIVERSAL::Data_Dumper may not even be needed, since it is trivial to check
>for defined(&Package::Data_Dumper)

Which means you don't use Inheritance.

> >I think I'd prefer a treatment of CODE refs that actually provoked a
> >warning on restoring.
>> I can add a warning, but like you say, a more complete treatment of coderefs
>> is not going to happen anytime soon (at least, not until there's internal
>> support for it in perl).
>
>Since writing, I've been wondering: how difficult would it be to track
>down code refs that appear in some symbol table?

That's not too hard, but it's not good enough: while you can (sometimes) do
a reverse lookup of CODE address to names, this doesn't deal with
the problem of closures in the subs.

$x = 77;

BEGIN {
my $x = 20;
sub something { return ++$x }
push @GF, \&something;
}

BEGIN {
my $x = 33;
sub something { return ++$x }
push @GF, \&something;
}

my $x = 57;
print &{$GF[0]}(), &{$GF[1]}(), &{$GF[0]}(), &{$GF[1]}(),
# merlyn's: print $GF[0]->(), $GF[1]->(), $GF[0]->(), $GF[1]->()

do_a_dump(\@GF);

Now, how might one properly dump @GF? Although this is an certainly an
obvious problem here in the previous code, such troubles can also
easily arise in simpler scenarios. The problem is getting the
no-longer-findable lexicals properly deeply bound in the closure. Perl
of course does this, but unless and until you've internal compiler
support for such things, and maybe not even then, I don't think it
feasible.

--tom