Re: [boost] Serialization and Reflection

From: Dave Harris (brangdon_at_[hidden])
Date: 2002-12-20 09:34:37

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

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.

In general, there needs to be a degree of abstraction between the 
published format used for serialisation, and the concrete representation 
as instance variables. 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.

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. 

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?

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.

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

-- Dave Harris