Dear Boosters, The Mirror library has been around for nearly a year. I would like to start doing the preparations for getting the library ready for a formal review and before that I would like to hear your opinions on whether this library actually belongs to Boost and any suggestions on how to improve it or what to change. For those of you who are not familiar with it, Mirror is a compile-time reflection facility with some run-time features. The sources can be downloaded from the Vault or checked out from the Sandbox (http://svn.boost.org/svn/boost/sandbox/mirror/) Since the docs (http://tinyurl.com/atba2k) do not cover everything yet, you can see the usage of several of the implemented but undocumented features in the test suite and in the examples (http://tinyurl.com/c4xygh). Some people have found the Concept browser (http://tinyurl.com/czz3t2) to be a good starting point and a useful quick reference. It, however, requires a XSLT capable web browser. It is known to work with MSIE 7+ and Firefox 3.x.y without the need to install any other software. Best regards, ________________ ::matus_chochlik
Matus Chochlik wrote:
The Mirror library has been around for nearly a year. I would like to start doing the preparations for getting the library ready for a formal review and before that I would like to hear your opinions on whether this library actually belongs to Boost and any suggestions on how to improve it or what to change.
For those of you who are not familiar with it, Mirror is a compile-time reflection facility with some run-time features.
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. - 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. So I don't see anything really compelling in it. Maybe a few use cases of your library would make me more interested?
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).
So I don't see anything really compelling in it. Maybe a few use cases of your library would make me more interested?
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Best regards, ________________ ::matus_chochlik
Matus Chochlik wrote:
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.
I don't know how familiar you are with Qt, but do you think you can write an example of a QAbstractTableModel which takes in a "mirrored" object and dynamically (or even statically) creates a custom model? Currently, I have some half-assed fusion-based code to do this. Thanks :-) -- Sohail Somani http://uint32t.blogspot.com
On Mon, Mar 30, 2009 at 6:13 PM, Sohail Somani <sohail@taggedtype.net> wrote:
Matus Chochlik wrote:
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.
I don't know how familiar you are with Qt, but do you think you can write an example of a QAbstractTableModel which takes in a "mirrored" object and dynamically (or even statically) creates a custom model? Currently, I have some half-assed fusion-based code to do this.
To be honest I'm not too familiar with Qt, but if You can provide me with the Boost.Fusion-based implementation I can give it a try ;-)
Thanks :-)
-- Sohail Somani http://uint32t.blogspot.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Best ________________ ::matus_chochlik
Matus Chochlik wrote:
On Mon, Mar 30, 2009 at 6:13 PM, Sohail Somani <sohail@taggedtype.net> wrote:
Matus Chochlik wrote:
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. I don't know how familiar you are with Qt, but do you think you can write an example of a QAbstractTableModel which takes in a "mirrored" object and dynamically (or even statically) creates a custom model? Currently, I have some half-assed fusion-based code to do this.
To be honest I'm not too familiar with Qt, but if You can provide me with the Boost.Fusion-based implementation I can give it a try ;-)
Ok, I'll email you the code when I can. -- Sohail Somani http://uint32t.blogspot.com
On Mon, Mar 30, 2009 at 5:49 PM, Matus Chochlik <chochlik@gmail.com> 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
Boost.Fusion allows mapping non-intrusively regular classes to fusion.sequences. And, FWIW, I have written complex applications using fusion tuples (heck, even plain tupes) instead of regular classes. -- gpd
On Mon, Mar 30, 2009 at 6:18 PM, Giovanni Piero Deretta <gpderetta@gmail.com> wrote:
On Mon, Mar 30, 2009 at 5:49 PM, Matus Chochlik <chochlik@gmail.com> 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
Boost.Fusion allows mapping non-intrusively regular classes to fusion.sequences.
I didn't mean to say Boost.Fusion couldn't do this. Mirror just tries to provide some more meta-data (which is it's primary function) then Fusion does. I'm not claiming that Mirror provides some completely new functionality in all areas that it covers, and in fact it's much more useful when used with other Boost libraries like for example Type Traits, MPL, Fusion, Serialization, etc.
And, FWIW, I have written complex applications using fusion tuples (heck, even plain tupes) instead of regular classes.
Hmm, it seems that my imagination is not so good afterall .. ;-)
-- gpd _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- ________________ ::matus_chochlik
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.
On Mon, Mar 30, 2009 at 8:40 PM, Edward Diener <eldiener@tropicsoft.com> wrote:
Matus Chochlik wrote:
[snip]
I would like to encourage you in your pursuit of compile-time/run-time reflection/introspection. But...
Thanks for the encouragement
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.
Yes, I guess this is not the best way to introduce a library to potential users. I did it this way because I wanted to get some opinions before I wrote the complete docs and have to rewrite them all over again in case there are some major objections to the public interface of the library.
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.
I see .. I'm going to write some more lifelike commented examples on the usage of the individual features.
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.
You always can separate the base-level declarations from the Mirror registering stuff by putting them into separate headers and include them both in the application sources. The only case when Mirror needs to be intrusive is if you want to reflect private member attributes not accessible from the outside and the intrusion is usually a one-line addition to the class' declaration.
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.
Sounds reasonable, thanks for Your suggestions.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Best regards, mch
participants (5)
-
Edward Diener -
Giovanni Piero Deretta -
Mathias Gaunard -
Matus Chochlik -
Sohail Somani