At 06:00 PM 8/21/00 -0700, Larry Wall wrote:
>[EMAIL PROTECTED] writes:
>: How about this then:
>:
>: In a void context, C<dump> dumps the program's current opcode representation
>: to its filehandle argument (or STDOUT, by default).
>
>It's not clear to me that reusing a lame keyword for this is the
>highest design goal. Let's come up with a real interface, and then if
>we want to reuse the (the presumably missing) dump keyword for some
>method name or other, that's fine. But we're currently designing it
>from the wrong end.
What I've been hoping for is:
1) The ability to dump the program and its current state out into something
that can be reloaded later. (Though filehandles and other
external-interface things make this tricky)
2) The ability to dump out a variable and all its attached state into
something that can be loaded in later somewhere else.
#1 is a natural outgrowth of bytecompiling a program--when you dump the
bytecode, you have already executed module initialization code and BEGIN
blocks, so that means variable dumps.
#2 is because I want to be able to do:
print SOME_SOCKET freeze_dry($an_obj)
and have the other end do:
my $remote_obj = reconstitute(scalar SOME_SOCKET);
Or something like that, at least...
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
