On Thu, Apr 26, 2012 at 5:06 PM, Julien Nitard <julien.nitard@m4tp.org> 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