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 input/output mechanism. 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
