Front page | perl.perl6.language |
Postings from August 2000
Re: Things to remove
From:
Dan Sugalski
Date:
August 23, 2000 09:33
Subject:
Re: Things to remove
Message ID:
4.3.2.7.0.20000823115045.00b98100@24.8.96.48
At 06:00 PM 8/21/00 -0700, Larry Wall wrote:
>damian@conway.org 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
dan@sidhe.org have teddy bears and even
teddy bears get drunk