Boost logo

Boost :

From: quendezus (quendez_at_[hidden])
Date: 2002-01-25 05:26:00


--- In boost_at_y..., Tom Becker <voidampersand_at_f...> wrote:
> Thu, 24 Jan 2002 14:16:22 -0000, "quendezus"
> <quendez_at_4...> wrote:
> >
> >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.
>

Agreed.

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

I agree with you. It seems to me sometimes you need persistence but
don't want to deploy an object database. Robert Stewart seemed very
doubtful about C++ persistence. Robert, could you explain your
position further?

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

I think I understand your point: you are saying that the persistence
mechanism should work with arbitrary type formats, and even with
multiple type formats. And so you want the persistence layer to
manipulate an abstract factory mechanism, configured by the user. In
theory, I should agree with you, but here is my reasoning:

1- You speak about multiple type formats, but what about
standardization? Maybe a boost library could decide for a format
(given that one format can fit all needs). If one format is accepted,
this simplifies a lot the interface of the factory system.

2- I think RTTI+ (or typeid_helper) is by far the best way to
implement the factory mechanism. This allows to benefit from the C++
RTTI and thus to provide a non intrusive system. We should discuss
this more. If one implementation is better, there is no need for an
abstract system. A concrete one will do.

3- Given points 1 and 2, I don't think abstraction is needed between
the factory and persistence layers. For me this would only make
things more complicated.

What do you think?

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

I understand. But it seems to me serialization (or static
serialization as you say at the end of your message) by itself needs
a lot of work: what about binary portability? Which relationship with
<iostream>?

Sylvain


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk