Re: [boost] Checking interest: reflectable types

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

On 4/29/2011 11:18 AM, John Bytheway wrote:
> 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.

Yeah, any time you reflect an object you get a compile-time hit.  Just 
using the objects isn't so bad.  So far it's been OK.

Another problem I've run into is that the compiler I'm using (VS2010) 
crashes if a boost::signals2::signal is the member of anything that is 
also included with a reflected object, if that signal's containing 
object is included first.  We're probably going to work around this by 
never exposing signals2::signals through public interfaces, using the 
pimpl idiom to hide them.  The connection seems to be OK so far.

My guess is that this has more to do with the signals2 library than with 
mine.  The compiler crashed in the same areas in earlier versions of the 
compiler but is now labeled as passing.  It could be that it only passes 
if you're not also doing a bunch of other template stuff within the same 
translation unit.

> - I couldn't see an easy way to get a public/private distinction on fields.

This could be done with private inheritance probably.  Also not sure it 
would be completely useful though since you can just make extra variable 
that aren't part of the reflected interface.

> - Understanding how it interacted with inheritance got rather mind-bending.
> - The syntax to access fields was just a little bit too tiresome.

It took some work but to access fields in mine it's: get<outer, 
inner,inner,inner>(object)

There's also a build_accessor that constructs a typedef out of an object 
type and a sequence of fields (in an mpl::vector for example).

>
> 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.

Yeah, that's probably a more accurate description.  Might be possible to 
merge into fusion somehow actually.

And yes, would be interesting to see what someone who really knows their 
stuff can do about compilation times...if anything.