On 27/04/11 19:53, Noah Roberts wrote: <snip>
Use of mine is more like so:
struct field0 { typedef int value_type; }; struct field1...2 ...
struct my_reflected_type : build_class < var< field0, rw > , var< field1, r > // can't assign through reflection. >::type { virtual ~my_reflected_type(){} DECLARE_PARAM_CONSTRUCTOR(my_reflected_type); };
struct my_reflected_type2 : derive_from < my_reflected_type , var< field2, rw > >::type { my_reflected_type2() : type(( field0() <= some_val , field1() <= some_val , field2() <= some_val )) { // directly access read-only value and assign... var<field1,r>::value = 66.; } };
I also have a ref<> so bases can have fields to abstract types.
So far functions haven't been needed here so there's none but I think I have a handle on how that could be done.
All of the above can be treated as a fusion sequence and/or fusion associative sequence (including the param list).
Building records on the fly with field()<=value syntax was very desired. Comes in handy when you have a function expecting a record with x,y,z fields in it, have those values, but don't want to build the record class.
I created something like this a while back and used it to write a program as an experiment in how crazy it would turn out to be. I didn't support named initialization of the fields; that's a good idea. If you'd like to see, my implementation is here and hereabouts: <https://github.com/jbytheway/nibbles/blob/0ce0577bb11d821614595f465da836f3c011664e/nibbles/utility/dataclass.hpp> but it's not really built for public consumption, and it looks like yours is rather nicer. I did enjoy it for a few reasons. It allowed me to write serialization support just once for all such structs (that was my primary motivation for the experiment), and write a deep comparison operator very easily. However, my conclusion was that the system was ultimately impractical on the scale I was using it for a few reasons: - Compile times were absolutely horrific; though these could no doubt be improved with attention. - I couldn't see an easy way to get a public/private distinction on fields. - Understanding how it interacted with inheritance got rather mind-bending. - The syntax to access fields was just a little bit too tiresome. It could be interesting for use on a small scale, and it would be nice if there were an implementation out there which had done the relevant compile-time optimization and ironed out the wrinkles. However, I would present it as a "Fusion map with extra bells and whistles" rather than a reflection library. John Bytheway