RE: RE: Pluto updated

["Virgil Smith" <Virgil@...>]

Grisha, thanks for filling in with clarifications concerning my suggestion.

Ben, as Grisha said there is no problem with multiple or cyclical references
in the "one stage" method so long as the object to be serialized is assigned
its reference value before serialization takes place.  Of course the same
procedure has to be applied on deserialization as well (which is probably
what is nagging at you Ben).  Adding the object to the "reference table"
before serialization is quite straight forward.  Adding it to the "reference
table" before deserialization is not quite as straight forward since
"obviously it doesn't exist before deserialization".

Basically, you have to perform "in place" deserialization.

For a table this is no problem whatsoever as you merely create the empty
table (and add it to the "reference table") before deserializing its
key/value pairs.  If a key or value directly or indirectly refers back to
the table there is absolutely no problem with forming the Lua reference even
though the table is not yet "complete".

Closures are a similar case provided that you can create the function before
modifying its upvalues (which I don't know off the top of my head), but then
if you can't do that then handling closures with cyclical references is
going to be a pain no matter what.

Userdata are no problem whatsoever because they can't reference anything
except their metatable, so you just serialize the userdata before its
metatable.

This sounds complicated when you explain it in detail, but its really
nothing more than knowing that you can't refer to what hasn't been named
yet.

---
As for "brittleness" in the file format the only possible difference between
the "one stage" and "two stage" approaches is that in the "one stage"
approach you have the option of eliminating the inclusion of the reference
values in the stream to tag each serialized value.  However, there is
nothing to say that you have to save that space in the stream, you could of
course include it with every serialized value (for instance right after the
type code, but before the rest of the value).

Other than that I can see no difference in the robustness of a "one stage"
approach as opposed to a "two stage" approach.  In fact I considered
suggesting the "one stage" approach after my first reading of Pluto because
Pluto's design was (at first glance) otherwise general enough to be used not
just in a "snapshot" fashion, but could also be used for continual
streaming.  (Being more specific I thought you could use it for
communicating over a network connection, rather than just for saving
something to disk.)  The "two stage" approach immediately seemed wrong to me
for such uses.  After just a little more reflection I realized that the "one
stage" approach wasn't really any better because any system that introduces
references must immediately cope with change tracking. (I can't just refer
to 'item 4' from my side of the pipe because I don't know if your copy of
'item 4' has changed.)




-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br
[mailto:lua-bounces@bazar2.conectiva.com.br]On Behalf Of Grisha
Sent: Tuesday, June 15, 2004 1:20 PM
To: Lua list
Subject: Re: RE: Pluto updated


Believe me, the above example will serialize any number of objects with any
references between them. If objects gets to the list first, and gets
serialized second there's no posssible problem with cycles.

Grisha

----- Original Message -----
From: "benjamin sunshine-hill" <bsunshin@usc.edu>
To: "Lua list" <lua@bazar2.conectiva.com.br>
Sent: Tuesday, June 15, 2004 11:12 PM
Subject: Re: RE: Pluto updated


> Ah, I see what you mean. I dislike how brittle and convoluted the file
format becomes, though. Also, I think there might be additional problems
when two objects refer to a same third object... a decreasing
reference-count might help, but the complexity gets rather onerous.
>
> ----- Original Message -----
> From: Grisha <grisha@eagle.ru>
> Date: Tuesday, June 15, 2004 11:47 am
> Subject: Re: RE: Pluto updated
>
> > Why is there a problem with cyclic references? There's no problem as
long as
> > you first add object to already serialized list, and only then actually
> > serialize it.
>