From: Tom Becker (voidampersand_at_[hidden])
Date: 2002-01-25 19:36:33
On Fri, 25 Jan 2002 10:26:00 -0000, Sylvain <quendez_at_[hidden]> wrote:
>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.
I'm all for promulgating a standard format. But as old programmers
know all too well, existing data formats will never go away. If we
can have a single library that can easily be adapted for different
formats, programmers will want to use it, and once they are using the
library, they will have a much better chance of seeing the advantages
of using the library's standard format.
A flexible serialization library could replace a lot of proprietary
code that's out there in the application frameworks. As someone who
has worked on a framework, believe me, this would be a good thing.
One thing that happens when a framework or an application has been
around for a while is the data formats evolve. Having some support
for multiple formats, or at least versioning, is a good thing.
The strongest reason, for me personally, is there's an application I
want to write that will have to interoperate with a wide variety of
persistent object formats.
I think the library should be forced to prove that it can handle a
wide variety of common formats, and it should also be simple and well
modularized. It should not require developers to learn about or pay
overhead for features they don't use. In my experience, the best way
to get to a really elegant solution is to try a lot of different
variations, see where the problems are, and keep pounding on the
design until it handles every variation in a clean way.
>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.
I agree that RTTI can be very helpful in this context, and there
should be a mechanism that leverages it. I just don't want to
position it as an extension of RTTI. This may be more of a semantic
and philosophical perspective than an actual practical design issue.
>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.
There should be a low overhead solution that makes you happy. There
may need to be some other stuff so I can be happy too, but it should
be optional and not get in your way. I hope that you will continue to
be involved in this discussion. Your questions have been very helpful.
I think we're at the point where it would make sense to start talking
about actual designs and code. Unfortunately, I don't have a lot of
free time at the moment, so it's going to be a little while before I
can post anything. Maybe there are others who have stuff they'd like
to put forward.
-- 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