Re: [boost] Checking interest: reflectable types

Subject: Re: [boost] Checking interest: reflectable types
From: Noah Roberts (roberts.noah_at_[hidden])
Date: 2011-04-27 14:53:45

On 4/27/2011 10:42 AM, Matus Chochlik wrote:
> On Wed, Apr 27, 2011 at 6:41 PM, Noah Roberts<roberts.noah_at_[hidden]>  wrote:

>> There is a boost.reflection proposal out there that is meant to work with
>> boost.extension.  This one is a bit different in that you're not
>> additionally defining data; instead you declare your reflection as you
>> declare your reflectable type through the instantiation of and inheritance
>> from template metafunctions.
>
> There is also the Mirror reflection library which I plan to
> submit for review once it is ready.
>
> The project homepage (with links to docs and download page)
> is located here http://kifri.fri.uniza.sk/~chochlik/mirror-lib/html/

Yeah, the original worked like that.  We found the manual registration 
process ungainly.  Also didn't do proper inheritance...which maybe yours 
does.  Had trouble looking at the docs and seeing how to use it since 
the part that probably does all the work (classes.h) isn't linked in 
with the examples.

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.