Re: [boost] [intro] Preview: Introspection library

Subject: Re: [boost] [intro] Preview: Introspection library
From: Stefan Strasser (strasser_at_[hidden])
Date: 2010-06-29 04:24:50

>>>>> template<class Mapping>
>>>>> friend void introspect(Mapping mapping,type<A>){
>>>>>   mapping
>>>>>     (base_class<A_base>()                  )
>>>>>     (member<A,int             ,&A::m_a>()  )
>>>>>     (member<A,float           ,&A::m_b>()  )
>>>>>     (member<A,std::vector<int>,&A::m_vec>())
>>>>>   ();
>>>>> }
>>>>
>
> I would be interested in some examples if you were kind enough to
> provide them.

for algorithms? serialization. see my initial mail for a list.
for concept implementation? I'll try my best, using your documentation  
only and the same class as above:

BOOST_MIRROR_REG_CLASS_BEGIN(class,test,A)
   BOOST_MIRROR_REG_BASE_CLASSES_BEGIN
     BOOST_MIRROR_REG_BASE_CLASS(_,public,A_base)
   BOOST_MIRROR_REG_BASE_CLASSES_END
   BOOST_MIRROR_REG_CLASS_MEM_VARS_BEGIN
     BOOST_MIRROR_REG_CLASS_MEM_VAR(private,_,_,m_a)
     BOOST_MIRROR_REG_CLASS_MEM_VAR(_,_,_,m_b)
     BOOST_MIRROR_REG_CLASS_MEM_VAR(_,_,_,m_vec)
   BOOST_MIRROR_REG_CLASS_MEM_VARS_END
BOOST_MIRROR_REG_CLASS_END

inherent in a reflection library is that the "registering" concept  
defined by it will be imposed on the library end user, i.e. if I write  
a library that needs reflection on types and I use Mirror for that, I  
require the user of my library to implement the mirror concept for  
each type.
besides my dislike for the use of macros, the user should not have to  
provide any information that isn't required by the component requiring  
reflection on (parts of!) that type.
the component using reflection might also require additional  
information provided by the user, e.g. in the case of a lot of Intro  
algorithms, whether a pointer refers to shared memory or not:

      (member<A,B *,&A::ptr_to_B,shared_pointer>()  ) //(1)

or tag names for XML serialization, or ...

I'm not saying that I have a better way to register classes/members in  
Mirror, I'm not even sure there is a better way.
just trying to explain why requiring the user of the library that uses  
Intro to register all his types in the way shown above wasn't an option.
I don't like the introspect() concept either and would have rather  
used Serializable, but it is the best I could come up with, and  
Serializable results in very inefficient algorithms especially when  
using more than one instance at a time (e.g. copying an object, or  
comparing 2 objects)

Stefan

(1)
shared_pointer is the default semantics for type "B *", so it doesn't  
have to be specified.
typedefed to  
semantics<mpl::set<unique,sealed>,semantics<mpl::set<shared,polymorphic> > >,  
i.e. the member ptr_to_B itself is unique, but the object it is  
pointing to might be pointed to by other pointers (shared), and might  
not have type B but a derived type.