From: Jeremy Maitin-Shepard (jbms_at_[hidden])
Date: 2002-12-18 20:17:51
On Wed, Dec 18, 2002 at 07:53:25AM -0800, craigp_at_[hidden] wrote:
> I agree. OTOH, I think a full-fledged reflection library will be some ways
> off. We could start with a bare-bones system designed to explicitly
> support serialization, but I think it would slow down the adoption of the
> existing serialization effort, and I'd rather not stir up more controversy
> (unless there's a clear benefit to doing so, which I don't see). Once a
> reflection library is more-or-less in place, extending it to handle
> serialization will be relatively straightforward, whether with a brand-new
> design or adapting it to an existing library.
In order to do serialization with reflection, there needs to be access
to class hierarchy, and a system by which all fields that are to be
serialized can be accessed and modified. However, fields that are
serialized would not neccessarily, and in fact generally would not
correspond to a single instance variable or an instance variable at
all. The only additional capability not needed for the "bare bones"
reflection library needed by serialization is access to methods, which
IMO is the simplest.
However, most reflection libraries, especially ones that attempt to
automatically generate the data, will simply provide access to
individual instance variables. For this reason, I think that
developing a reflection library without serialization in mind might
result in a library that is simply unusable for serialization.
On the other hand, a serialization library that does not make use of
a reflection library but does handle deserialization of pointers to
derived types requires a system for registering class hierarchy.
Also, a serialization library that is not based around reflection/meta
data would be quite different from one that does.
It therefore seems that if we were to implement a reflection library
and a serialization library separately, and then tried to integrate
them later, we would likely find that both would need to be partly or
almost completely re-written. For example, the only part of a
serialization library that is not based on using reflection data that
could be reused in one that does would be the data-formatting code.
- Jeremy Maitin-Shepard
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk