Re: [boost] [reflect] Introducing Boost.Reflect

Subject: Re: [boost] [reflect] Introducing Boost.Reflect
From: Daniel Larimer (dlarimer_at_[hidden])
Date: 2011-08-01 10:55:42

On Sun, Jul 31, 2011 at 4:11 AM, Matus Chochlik <chochlik_at_[hidden]> wrote:

> Hi Daniel,
>
> On Sat, Jul 30, 2011 at 11:05 PM, Daniel Larimer <dlarimer_at_[hidden]>
> 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