Subject: Re: [boost] [OT][RFC] standardized compile-time reflection
From: Julien Nitard (julien.nitard_at_[hidden])
Date: 2012-04-26 11:06:31
Hi again,
>> 4) Should mirror< mirror< T > > work?
> There is a MetaMetaObject concept in Mirror, but I've been
> kind of struggling in its design. It is useful in some cases though.
But I guess limited cases I guess, since there will be just a few
types of metaobjects (struct/class, member, function, template,
namespace ...)
> > 5) Should conversion ever work the opposite way? Should I be able to meta-programatically generate types from your representation:
> > typedef unmirror< addField< mirror<T>, "member", int> > NewT;
> >
> > Obviously that would require a ton of compiler magic, but might be something to think about. Is your representation easy to manipulate/generate? How cubersome would addField<> be?
> >
>
> I've also thought about this, IMO such feature would find a lot
> of use-cases and open "new horizons" :) for compile-time
> meta-programming, but designing and implementing it might
> be quite difficult.
>
> I'm not sure what the compiler vendors would say to that.
> Also I don't want the proposal to be too bloated. Too much
> complexity is IMHO one of the reasons why C++0x concepts
> were rejected.
>
I guess this is not reflection any more, it's code generation. It's
already possible to combine types rather easily (don't need the
compiler's help) with new fields by using inheritance + CRTP,
std::tuple or boost::mpl::vector. The reflection metadata will
probably be easy to feed to any meta programming library without the
need to add anything to the proposal. … Or am I missing something
?
One more thing that's missing from the proposition is annotations (as
in "user defined metadata"). I'd be happy to have those as well. An
annotation could be a list of objects of arbitrary type associated to
a reflected object.
The motivational example is formatting an object to XML/Json/CSV to be
able to override the default serialization by the user.
Doing it without the compiler's help is already possible for some
objects (types and members) by specializing a template on the type or
pointer to member to be annotated, though I guess some new syntax
would be required to make the life of the user easy.
Finally (for today ;), you don't mention the interactions of Mirror
with RTTI in the paper (though there are some from the docs). I guess
it should be possible to get the reflection information from the
typeid and vice versa.
Regards,
Julien