Subject: Re: [boost] Checking interest: reflectable types
From: John Bytheway (jbytheway+boost_at_[hidden])
Date: 2011-04-29 14:18:11
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:
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