Matus Chochlik wrote:
On Mon, Mar 30, 2009 at 3:59 PM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
Matus Chochlik wrote:
[snip]
From a quick reading of the documentation, I can see this library allows: - to register members of a class and to be able to iterate them later at compile-time. That kind of thing is already provided by Boost.Fusion somehow.
Yes, Boost.Fusion allows this, but I can't imagine any complex application using just Fusion tuples instead of any regular classes. Furthermore Mirror can work with existing third-party classes and with classes that have private members accessible only by get/set member functions.
- to demangle the result of std::type_info::name - to remove the namespace information from the demangled name - to do some tests on namespaces which seem quite arcane and not very useful to me.
Well, these are just the very basic use-cases of Mirror, I have to admit that the examples in the documentation don't cover any more complex cases, yet.
Just to mention some of the more useful features:
- namespace member iteration and traversals, which provide means to iterate through nested namespaces and/or classes in a reflected namespace (http://tinyurl.com/cg8f74) or to traverse them recursively by custom visitors.
- class traversals which allow to go through the class' structure (base classes, member attributes) recursively by a custom visitor and optionally to work just on the static structure itself or work on actual instances of the traversed class.
This way generic serialization-like algorithms or algorithms doing object-relational mapping which have a lot of useful meta-data available, can be easily written. Since Mirror registers and allows to work with the names of class member attributes it can work with data formats using the attribute names (like JSON, XML, etc.) more conveniently than Boost.Serialzation does (but obviously Mirror is not seeking to replace Boost.Serialization ;-)). (see for example here: http://tinyurl.com/d5ywwb, here http://tinyurl.com/ccf2rq or here http://tinyurl.com/ccoagk)
- intrinsic functions and iterators allow to iterate through class' members and base-classes or to search for meta-objects satisfying compile-time predicates (http://tinyurl.com/dk4d2a)
- algorithms like 'for_each' allow to execute custom functors on meta-objects reflecting namespace members, class member attributes, base-classes, etc.
- meta-data provided by class' constructor reflection allow to construct generic class factories (an example an automatically generated wxWidgets-based class factory which can construct any type with constructors registerd with Mirror can be found here: http://tinyurl.com/crqyxs).
I would like to encourage you in your pursuit of compile-time/run-time reflection/introspection. But... You need to fully document your library rather than producing examples and assuming that people will be able to pick up its functionality from them. In your documentation I could not see where there is a clear explanation of how to get a class's functions and data, along with their corresponding types and member names. In other words you need to present co-ordinated documentation which shows how and what can be introspected from any given level. That I can create macros, which create underlying templates for metadata, for C++ constructs I generally understand, but how they are actually used needs much better documentation and not just random examples. Also whatever I saw looked pretty intrusive. I could not understand if your library has the ability to create metadata from types in header files without modifying the files. I would also strongly suggest that for the first iteration of your library you strive to present a single way of defining or using anything for simplicity's sake. As an example, forget about the macros which are just another name for another macro and present a single macro which does a particular thing. Ditto for everything else. If you attract people to the use of your library, you can then create as many shortcuts as you like in order to make things more flexible, but in the beginning you should strive to make things as easily understandable as possible and as uncomplicated as possible from the end user's point of view.