From: Dave Harris (brangdon_at_[hidden])
Date: 2002-12-20 09:34:37
On Thu, 19 Dec 2002 17:16:49 -0500 David Abrahams
> > 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
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
-- Dave Harris
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk