At 11:28 AM 25/04/2001 -0400, Uri Guttman wrote:
>well, the real goal is persistancy, so how about this idea?
>
>instead of using Data::Dumper and cousins to stringify a structure,
>write it out and parse it back in, we provide a module which copies and
>converts a structure to an area and converts all of its pointers to
>offsets. then that can be written out in one binary chunk. reading it
>back in and converting back to real pointers will be much simpler and
>faster than any string parser... [snip]
Well, the problem I see is when you have many different objects and you
would like to have views of that system. For example, suppose object A has
references to B and C, and that object D has references to B and C. If A, B
and C are in the same AREA so that they can be serialized together as one,
serializing D would be a problem, since probably A would go together with B
and C or the AREA structure would have to be disassembled.
I think we could use this to implement every structure (scalar, string,
array, hash) in a contiguous memory area, using offsets to point to
internal data, so that each separate object, like A, B or C, could be taked
from memory and saved to a stream. Reading the stream and placing the read
data into the memory, whatever position in memory it would be, would
re-assemble the structure correctly.
This could be done on a per-vtable base. For example, if we add
SERIALIZE/DESERIALIZE entries on vtables, objects that implement their
internal structure with contiguous allocated areas independent of initial
position in memory, could implement SERIALIZE and DESERIALIZE trivially by
only writing this memory area to a stream and by reading some bytes from a
stream and placing it somewhere in the memory, all offsets would work as
expected.
OTOH, vtables that need to use split memory areas or that make reference to
external objects, could have customized SERIALIZE and DESERIALIZE methods
to handle their complexities and details.
- Branden
