|
Boost : |
From: Tom Becker (voidampersand_at_[hidden])
Date: 2002-01-24 14:26:51
Thu, 24 Jan 2002 14:16:22 -0000, "quendezus"
<quendez_at_[hidden]> wrote:
>I would be very interested in discussing about a persistence library
>proposition. However, I find the few messages already posted on the
>subject not very clear to me. It seems many important issues are
>taken for granted.
>
>1-
>Is this a common need ? What should the library do ?
In applications that use objects to manage user data, persistence
makes saving and opening documents much easier.
It's common to use persistence to store window layouts and the
initial state of application objects. This makes programming easier,
and it's a huge help for internationalization.
Persistence can also be helpful for distributed objects. The objects
are sent and received, rather than saved and restored.
One thing we haven't talked about is automatically saving and
restoring objects. I think that gets into object database territory,
and it should be beyond the scope of a persistence mechanism.
>2-
>I have the feeling that a persistence library would need the
>following mechanisms:
>- a RTTI+ system that should allow object creation at runtime, based
>on type information (I call it RTTI+ to indicate that it has more
>functionalities than the standard C++ RTTI).
It's also been called typeid_helper. The problem with basing
persistence on RTTI is it hard wires the record formats to the type
id. I've worked on systems that do this, and it's nice until you have
to interoperate with different formats, and you have to create a
whole new mechanism. What we really need is just an object factory
mechanism that allows multiple factories.
>- a serialization system that would give facilities to serialize and
>deserialize objects into a kind of "storage".
>In my work as a developer, I need these 2 mechanisms alone more often
>than a persistence library. But anyway, I don't think it is possible
>to make a persistence library without them.
That's right. That isn't quite the same thing I want to do, but they
don't necessarily conflict. I don't see a huge difference between
serialization and persistence. Persistence is just serialization of
pointers, allowing for all the things that can happen with pointers
such as polymorphism and sharing.
>3-
>Given that a persistence library is needed, I think RTTI+ and
>serialization should have their own boost libraries. The reasons are:
>- I find each of these domains difficult, with many issues,
>especially if you want to provide simple and generic code.
>- Boost users could benefit for such libraries. For example, I use
>RTTI+ heavily for plug-in systems and script parsing (without any
>need for persistence). I use serialization without persistence when I
>want to implement simple load/save code.
Perhaps "persistence" is not the best word to describe it. I'm just
going to toss out some other terms and see what people think:
Static serialization
Dynamic serialization (instead of persistence)
Object factory (instead of RTTI+)
Dynamic serialization requires an object factory. Static
serialization does not.
Thanks,
Tom
-- Tom Becker "Within C++, there is a much smaller and <voidampersand_at_[hidden]> cleaner language struggling to get out." -- Bjarne Stroustrup
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk