Re: [boost] [mirror] -- RFC

Subject: Re: [boost] [mirror] -- RFC
From: Edward Diener (eldiener_at_[hidden])
Date: 2009-03-30 14:40:32

Matus Chochlik wrote:
> On Mon, Mar 30, 2009 at 3:59 PM, Mathias Gaunard
> <mathias.gaunard_at_[hidden]> 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.