Subject: Re: [boost] [OT][RFC] standardized compile-time reflection
From: Matus Chochlik (chochlik_at_[hidden])
Date: 2012-04-26 12:06:56
On Thu, Apr 26, 2012 at 5:06 PM, Julien Nitard <julien.nitard_at_[hidden]> wrote:
> 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 ...)
AFAICT all the cases where I used the MetaMetaObject could be
re-implemented by using the meta-object-traits, so this is IMO not
a critical feature.
>
>
>
>> > 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
> ?
e
Yes, variadic templates + multiple inheritance allow to do similar things
even if not all that would be possible with this feature.
The above were more musings than a proposal to add the said feature :)
>
>
> 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.
Actually (something similar to) this already IS covered by the paper,
for exactly the same reasons that you mention :) See the section
3.4. Annotations and relations and also "Unresolved Issues".
What is unresolved is the mechanism of annotations and
how exactly it would be reflected by the meta-object, but the
latter is a minor problem. It is on the TO DO list.
>
>
> 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.
>
This is intentional. This proposal deals with static compile-time
reflection and RTTI is (mostly) dynamic. On the other hand
any run-time reflection facility built on top should cooperate
or extend the current RTTI.
Best,
Matus