Re: Pluto updated

[benjamin sunshine-hill <bsunshin@...>]

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).