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. 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 ? :) 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.
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.
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.
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/