Subject: Re: [boost] [OT][RFC] standardized compile-time reflection
From: Julien Nitard (julien.nitard_at_[hidden])
Date: 2012-04-26 11:06:31
>> 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,
> > 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk