Re: [boost] Serialization and Reflection

From: David Abrahams (dave_at_[hidden])
Date: 2002-12-20 10:19:27

brangdon_at_[hidden] (Dave Harris) writes:

> In-Reply-To: <u4r99mz72.fsf_at_[hidden]>
> On Thu, 19 Dec 2002 17:16:49 -0500 David Abrahams 
> (dave_at_[hidden]) wrote:
>> > This is interesting, but to me it mostly confirms that I don't want a 
>> > reflection framework. It is at the wrong level of abstraction, in 
>> > that it deals with methods and instance variables rather than fields.
>> 
>> What's a "field"? In particular, please compare/contrast with
>> "instance variable".
>
> A "field" is part of the interface - in this case, the serialisation 
> interface. An "instance variable" is part of the implementation.
>
> Often fields will be represented by instance variables directly, but 
> sometimes not. For example, a Rectangle might expose fields TopLeft and 
> Size while using TopLeft and BottomRight internally. (Serialising as Size 
> will often save space in variable-length formats; the high bits of 
> BottomRight are probably the same as the high bits of TopLeft so we can 
> save some space by not storing them.)

OK, I get the concept.

> Sometimes instance variables will not need to be stored because they are 
> caches; ie they can be recalculated from data which is stored. For 
> example, we might store the points of a polygon but not the bounding box. 
> So not all instance variables correspond to published fields.
>
> Sometimes redundant fields may be wanted. For example, we might not cache 
> the bounding box, but we might expose it as a field anyway.

Yup.

> In general, there needs to be a degree of abstraction between the 
> published format used for serialisation, and the concrete representation 
> as instance variables. 

Not least for versioning.  And also because data members may be const
or not publicly accessible.  Ultimately, one may need to use the
class' constructor or other means to create it.

> The serialisation form usually needs to be more 
> stable, more invariant over time, so that we can continue to load old 
> files easily. It also needs to be more minimal, to save space in the 
> archive.

Depends on your definition of "needs" ;-), but OK.

> Many reflection systems, especially automated ones, work by accessing 
> language-level implementation details such as class names, method names 
> and variable names. That is how it is in Java, for example. I gather 
> Stroustrup's XTI will be the same. An automated system cannot tell fields 
> from instance variables - you need the intent of the programmer for that. 
> So I distrust solutions with a lot of automation. 

OK.

> On the other hand, if it isn't automated, I am concerned about the amount 
> of work I'll have to do.  Will a general solution for reflection be more 
> work than a more specific solution just for serialisation?

I don't know.

It sounds like building serialization code might be an interactive
process.

For each class to serialize/deserialize, what are the axes of
variability?

* factory to use
* constructor args (possibly none)
* post-construction initialization (possibly none)
...

I also wonder if there's any way to handle versioning that doesn't
result in a wad of ad-hoc code for each versioned class.

> Also... suppose we want to use reflection to connect UI widgets to 
> application objects. It seems to me the fields I want to expose to the UI 
> may not be the same as the ones I want to use for serialisation.

I think once we're talking about fields, we're no longer talking about
reflection.  As I understand it, reflection means the ability to
discern the structure of language constructs. As you point out, fields
are not neccessarily present in the language.  

> (However, I can see that some components of a serialisation library,
> such as the mechanism to register object factories, ought to be
> sharable with a reflection library.)

Hmm, how does an object factory relate to reflection?

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution