Re: Pluto updated

["Grisha" <grisha@...>]

Hi, Ben!

We have such a system up and running, and it's not that complex at all, I
can send it to you if you wish. You are right, Pluto doesn't have to know
anything about how C++ objects are serialized, same as C-side must know
nothing about how Pluto does it's job. What I'm asking for is just to
recieve those context parameters passed to Pluto (reader/writer & (void
*ud)) back in persist/unpersist methods. This will not complicate things
much for either you, as Pluto developer, or any other programmer working
with Pluto (they will just ignore extra parameters).

-- modified text from Pluto\readme
Here's an example of special persistence for an object:

vec = CreateMyObject()
setmetatable(vec, { __persist = function(oldtbl, writer, ud)
 local mt = getmetatable(oldtbl)
 local state = DoCSideSaving(oldtbl, writer, ud)

 return function(newtbl, reader, ud)
  setmetatable(newtbl, mt)
  DoCSideLoading(newtbl, reader, ud, state)
 end
end })

Note that original example will work too, since it will just ignore extra
parameters. We really need this, we can live without function or thread
persistance, but without proper uderdata persistance we can't.

Thanks in advance,
Grisha

----- Original Message ----- 
From: "benjamin sunshine-hill" <bsunshin@usc.edu>
To: "Lua list" <lua@bazar2.conectiva.com.br>
Sent: Saturday, June 12, 2004 1:17 AM
Subject: Re: Pluto updated


> Hmmm..... it's a tricky issue that you raise. After all, Pluto's designed
to serialize a bunch of interreferencing Lua objects, rather
interreferencing C++ objects. A system capable of serializing C++ objects in
a parallel manner would be complex indeed. Still, I really think that the
current situation will work. What would need to be done would be for the
__persist functions to invoke the C++ persistence framework in such a way
that temporary Lua objects--userdata, most likely--were created to
encapsulate the object state. If objects are shared between different
userdata (using some custom C-side reference counting mechanism, for
instance), some registry-related method could be used to coordinate
serialization between different C object entry points. This is, of course, a
rather complex method... but it's really not much more complexity than
absolutely necessary to serialize a C++ framework. Pluto would still
automatically handle fixup before running the unpersistence method
> s, of course.
>
> Ultimately, I don't think that the main question is whether the __persist
metamethod writes through a string/userdata or through a writer object;
that's just semantics, with some performance implications. The real question
is how much control __persist can exert over the serialization stage, and
how much control it has over internal Pluto placeholder references. I'd
really prefer to keep those as hidden implementation details; they've
already gone through a couple of revisions, and there are quite a few
caveats that they deal with in order to keep Lua happy.
>
> Ben
>
> P.S. I'm currently working on the string-keys-for-permanents idea you
proposed. It's proving to be more difficult conceptually than I'd expected,
to maintain flexibility and provide as much user-control as possible, but I
should have it ironed out in a week or so (travel will be slowing me down).
>