From: Jeremy Maitin-Shepard (jbms_at_[hidden])
Date: 2002-12-17 16:25:39
On Tue, Dec 17, 2002 at 08:37:00PM +0000, Dave Harris 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.
> I also don't trust an automated versioning system to get versioning right
> in complex cases.
I agree that a traditional reflection framework would not be
suitable. However, with serialization in mind, I think we can design
a reusable reflection framework that will be suitable. For example,
it seems most reasonable to provide a system by which fields can be
specified, where functors for getting and setting the value must be
specified. In addition, by providing a mechanism by which the
automatic versioning system can be overridden for a specific field,
for example providing a custom default initialization (in case that
the field is not available in a particular version) or a custom cast
in case that the type of the field changes and custom initialization
of base classes in case of changes to class hierarchy.
> (I am also concerned about the overheads of using reflection to implement
> the simpler kinds of serialisation.)
This problem can be avoided by using metaprogramming techniques to
essentially move the reflection to compile-time, such that perhaps
only a single virtual method call is needed per aggregate type/UDT, which
is quite reasonable considering the overhead caused by the underlying
There are many similarities between this and the Spirit parser
framework, and the Spirit parser provides a good example of how such a
framework can be both extremely flexible while also efficient.
- 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