Re: stringification of objects, subroutine refs
On Sat, 2002-05-11 at 00:39, Dan Sugalski wrote: At 8:58 PM -0700 5/10/02, [EMAIL PROTECTED] wrote: I was wondering how perl6 would stringify (as in Data::Dumper): That's not stringification. It's serialization, which is a different thing entirely. What you'll potentially get is a thing that can be completely reconstituted into what it originally was, complete with variables, methods, attributes, and whatnot. How much gets serialized depends on what you'll choose--in the worst case, your entire program will need to get serialized, but that'll be doable. This seems like a no-brainer to me, so I must be missing something ;-) Wouldn't it be possible to just settle on Parrot byte-code as a serialization form? If so, everything is serializable, no? Granted, your data might not come out intact if your writer and reader don't agree in module versions, but this is a minor nit in the scheme of things.
Re: stringification of objects, subroutine refs
At 10:10 AM -0400 5/15/02, Aaron Sherman wrote:
On Sat, 2002-05-11 at 00:39, Dan Sugalski wrote:
At 8:58 PM -0700 5/10/02, [EMAIL PROTECTED] wrote:
I was wondering how perl6 would stringify (as in Data::Dumper):
That's not stringification. It's serialization, which is a different
thing entirely.
What you'll potentially get is a thing that can be completely
reconstituted into what it originally was, complete with variables,
methods, attributes, and whatnot. How much gets serialized depends on
what you'll choose--in the worst case, your entire program will need
to get serialized, but that'll be doable.
This seems like a no-brainer to me, so I must be missing something ;-)
Wouldn't it be possible to just settle on Parrot byte-code as a
serialization form? If so, everything is serializable, no?
Mostly, yes, if we put aside the issue of code written in C.
There is the issue of how much gets serialized, and how things get
reconstituted, which is where things get interesting. Assume this:
package foo;
our @ISA = (Rezrov);
my $bar;
$foo = sub {$bar++};
$baz = sub {$bar++};
if you serialize and reconstitute $foo *and* $baz, should they share
a $bar? Should all of Rezrov be serialized with them and, if so, do
they each get a private copy? Do they both see the same @ISA, as its
global?
It's all doable, of course, and as much a matter of policy on
serializing and reconstituting.
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: stringification of objects, subroutine refs
Brent Dax [EMAIL PROTECTED] writes:
[EMAIL PROTECTED]:
# I was wondering how perl6 would stringify (as in Data::Dumper):
As Dan said, that's serialization. I don't know if Perl will support
that built-in. But if it does...
# 1) objects with 'my' and 'our' variables
Those would have to be dumped from the pads or stashes. I don't think
there's any way around that.
The semantics of this are unclear. Say I have (sorry if the syntax is
wrong)
{
my $t;
my ($x,$y) = (- { ++$t }, - { $t-- });
}
(The intent is I can use C$x.() and C$y.() to count backwards and
forwards).
Now, if I say Cprint FH serialize($x,$y) (assume suitable encoding,
delimiting, etc.; I'm not asking about those), I'd expect to get a
copy of C$x and C$y, and they should share the same C$t. Right?
What does the list C($x.serialize(), $y.serialize) give me? Given
that there's no way to know that both serializations will end up going
to the same file, they have to give me the equivalent of
{
my $t;
my $x = - { ++$t };
}
{
my $t;
my $y = - { $t-- };
}
So we've broken the meaning of the code (and serialization can't just
be a UNIVERSAL method, we have to be able to call it as a function on
a list). Is this a Good Thing? (Can we Do Better???)
OK, so now say I'm reading the original (Cserialize($x,$y)). And I
do it twice. Following the previous logic, I get 2 copies of C$t,
one for each reading. This might make sense, or it might not.
How do I read half of Cserialize($x,$y)? (That is, can I get just
C$x?) The easy answer is to say I can't. This creates an
uncomfortable situation. Every time I want to serialize a bunch of
closures, I have to serialize all of them in one go. And I have to
deserialize them all if I want to access any bit of them. What do I
do if I have 10_000 copies of some huge bunch, and I want to access
just one bit of it? Seems like I have to deserialize everything --
even though Ifor this case we could be doing a lot better!
I guess I just don't understand how serializing closures is supposed
to work.
[...]
--
Ariel Scolnicov|http://3w.compugen.co.il/~ariels
Compugen Ltd. |[EMAIL PROTECTED]Sometimes people write an
72 Pinhas Rosen St.|Tel: +972-3-7658117 accidental haiku. Damn!
Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555 It just happened!
RE: stringification of objects, subroutine refs
[EMAIL PROTECTED]:
# I was wondering how perl6 would stringify (as in Data::Dumper):
As Dan said, that's serialization. I don't know if Perl will support
that built-in. But if it does...
# 1) objects with 'my' and 'our' variables
Those would have to be dumped from the pads or stashes. I don't think
there's any way around that.
# 2) $.property
Using their accessors?
# 2) subroutines (and coderefs)
See my comment below.
# 3) properties (both is/has)
'is' properties are part of the code, so I don't think they need
serialization. 'has' (or whatever it'll be called) properties can be
applied easily--remember, a 'has' returns its left operand.
# Right now, the fact that subroutines come out as 'sub {
# DUMMY }' is a minor pain to work around, having all of
# these as holes would be too much IMO.
That's fixed in 5.8--it uses B::Deparse to make a rough version of the
sub. Just hope it isn't a closure.
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
blink: Text blinks (alternates between visible and invisible).
Conforming user agents are not required to support this value.
--The W3C CSS-2 Specification
Re: stringification of objects, subroutine refs
At 8:58 PM -0700 5/10/02, [EMAIL PROTECTED] wrote: I was wondering how perl6 would stringify (as in Data::Dumper): That's not stringification. It's serialization, which is a different thing entirely. What you'll potentially get is a thing that can be completely reconstituted into what it originally was, complete with variables, methods, attributes, and whatnot. How much gets serialized depends on what you'll choose--in the worst case, your entire program will need to get serialized, but that'll be doable. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
