Re: [boost] Checking interest: reflectable types

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:

<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