On Sun, Jul 31, 2011 at 4:11 AM, Matus Chochlik <chochlik@gmail.com> wrote:
Hi Daniel,
On Sat, Jul 30, 2011 at 11:05 PM, Daniel Larimer <dlarimer@gmail.com> wrote:
On Jul 30, 2011, at 4:40 AM, Jose wrote:
I hope you propose boost::reflect for review soon and then mature all the other bits in a library that enables other concurrency models and is a good brother for asio.
I take it as a high complement that you consider boost::reflect worthy to be considered for review soon. I am willing to submit it if I can can get enough feedback on it.
Your RPC library certainly looks interesting, but I've a few questions/comments on the reflection part.
1) Does the name describe what it does?
Basically yes, but from a quick glance at the docs I'm missing a few things (see below). Generally from my own experience I can say that a reflection library should not start as the support tool for a particular task (RPC, serialization in this case). It should aim to be as general as possible, as there are other situations where reflection can be useful.
I can only agree with you in part. If the requirement to be as 'general as possible' makes the resulting solution less optimal for the most common use cases (RPC, Serialization, etc) then your API will be much more difficult for 99% of the use cases so that you can support the 1% special cases. This, I believe, is the primary difference in our design philosophy.
Mirror (the C++03 and C++11 version) are the third and fourth reflection libraries I've written from scratch ;) The first was begun actually the same way as Boost.Reflect as a support for RPC and it worked well for this task but it had two main problems it was too polymorphic (= too slow) and too specific (= not usable for other things)
2) Does the library fully address the problem within the scope of practicality?
If its goal is only to be the support for RPC then yes. Have you considered using another more general reflection library (shameless plug) like Mirror ? :)
Yes, but see prior comment regarding ease of use vs. general solution.
In the past I preferred to work on it alone since I had my ideas about how to do certain things. But now it is in a state where a second (and preferably third, fourth, ...) opinion would be very helpful. If your are missing something in Mirror I'm sure we could get it done
Perhaps if Boost.Mirror provided a "quick and dirty" macro that does what BOOST_REFLECT(type, (base)(base2),(member)(member2)...) does then I could leverage it. That said, Boost.Mirror currently depends upon C++0x features not available in Visual Studio. Also, even with a simplified macro, Boost.Mirror's greater complexity/flexibility mean significantly longer compile times. Ideally, the reflection should be light-weight enough that users automatically add it to everything so they can benefit from automatic serialization, json, debug output, and many other tools that can leverage reflection. If adding reflection doubled my compile times then that may be a show stopper for many people. When it boils down to it, most of my reflection for basic types amounts to a simple function defined by a macro: template<typename T, typename Visitor> visit( Visitor v ) { visit<BaseA>(v); visit<BaseB>(v); v( &T::name, "name" ); v( &T::member, "member" ); } Combined with specializing get_typeinfo to get a cross-platform alternative to typeid(T).name(); template<typename T> struct get_typeinfo { static const char* name() { return "ClassName"; } } And a few built-in helpers for vector,map,list,pair, etc.
.
3) Other reflection attempts have not been accepted for one reason or another. - Boost.Reflect vs Boost.Mirror
Here should be probably said that Mirror (and AFAIK) Boost.Reflection were not submitted for review (yet) and this is the only reason for them not being accepted. I don't know about Jeremy but I'm planning to do that once it is ready.
The compile-time reflection is basically finished (with a few things that need polishing and a few features that can be added later).
The two biggest problems I see are that it heavily depends on C++11 and some quick start guide and step-by-step tutorials are missing from the docs.
There is also a significant amount of 'reflection' provided by BOOST_FUSION_ADAPT_STRUCT macro. In fact, I suspect that with the addition of a 'name_of<tag>' that it would provide all of the runtime/compile time reflection necessary for doing serialization. Unfortunately, boost::fusion, and I suspect Boost.Mirror would introduce substantially more compile time overhead than Boost.Reflect when you consider the number of types / meta functions created/evaluated. The benefit of BOOST_FUSION_ADAPT_STRUCT is that your types are ready for use with Boost.Spirit. Also, BOOST_FUSION_ADAPT_STRUCT cannot be used to reflect methods.
4) Would a different name better 'reflect' what the library does? 5) Are there any features missing?
I couldn't find things like namespace member traversals, support for compile-time metaprogramming, reflection of specifiers (access type, linkage/storage class, etc.) examining/setting members with getter/setter functions (with side effects), just to name some, but maybe I just missed them in the docs.
Most of those things are not there because they were not in the design
spec. Based upon these comments and the fact that Boost.Mirror is far more robust than my code, I think the question becomes which is better: 1) Move Boost.Reflect into Boost.RPC 2) Provide a simpler macro interface to Boost.Mirror 3) Two different reflection libraries 4) Move BOOST_REFLECT_ANY() into a Boost.Erasure library, simplify Boost.Mirror macros. 5) Added a small bit of reflection to BOOST_FUSION_ADAPT_STRUCT The last thing I want as an end-user is to specify BOOST_REFLECT..., BOOST_MIRROR..., and BOOST_FUSION... for all of their types. I suspect there is a place for all 3 solutions as they all make different tradeoffs in performance, flexibility, and compile times.
6) What must be done before it can be submitted? - license info, unit tests, etc?
Would it be more aptly named for its type-erasure, vtable, any_ptr<>, interface than its simple visitor-based reflection?
The library is ready for informal review now and my goal is to morph it into something that is ready for full review (as quickly as possible), so any feedback / direction would be very helpful.
Best,
Matus
author of the Mirror reflection utilities http://kifri.fri.uniza.sk/~chochlik/mirror-lib/html/ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost