In-Reply-To: <[EMAIL PROTECTED]> On Thu, 19 Dec 2002 17:16:49 -0500 David Abrahams ([EMAIL PROTECTED]) 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
