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