Re: [boost] Reflection?

Subject: Re: [boost] Reflection?
From: Matus Chochlik (chochlik_at_[hidden])
Date: 2008-11-04 03:14:33

Hi Jean-Louis,

I've merged several of Your posts so I can reply in one message,
lazy me, sorry ;-P

> I'm taking a look at it. It looks like my work picks up where yours stops.
> It is certainly worth making my library capable of perusing mirror's compile-time info. Or maybe my work should be merged in mirror...

I was thinking about writing a separate run-time library that would
use Mirror as the
source of the basic compile-time info. My idea is to define an
abstract interface
similar to the mirror's but polymorphic.

> I'll try to upload my stuff to the sandbox before leaving for vacation this thursday.

I would be glad to work together with somebody on this, but I ain't going to
make any promises ;), because right now I'm in a kind of deadline situation
so don't have much free time to work on Mirror.

Actually we've talked with Joel Falcou that we could work together,
but ... since then I hardly found some time to work on the mirror docs.
Hope it will be better at the end of this / the beginning of the next year.

On Tue, Nov 4, 2008 at 12:17 AM, Jean-Louis Leroy <jl_at_[hidden]> wrote:
> Jeremy Pack wrote:
>>
>> Jean-Louis,
>> Boost.Reflection handles multiple and virtual inheritance fine.
>
> Does the version from
> http://boost-extension.blogspot.com/2008/07/latest-release-downloadable.html
> contain support for inheritance already?
>
> My primary interest is not in reflection per se, for me it's just a tool
> upon which one can build generic object-processing tools like dumping
> objects to text descriptions or XML or implementing object-relational
> mapping.

Support for serialization and object-relational mapping is also
one of my motivations for writing a compile time reflection library.

Actually it is sad that the C++'s "reflection" abilities are limited
to ::std::type_info, the typeof operator and bunch of other stuff,
because compilers have a lot of useful information that the programmers
could use, but cannot access in any portable and standardized way.

The potential authors of a proposal of a good compile-time reflection facility
for C++ will be my heroes. :)

Sure, there are tools like gcc2xml, openC++ and some others but
most of them are platform/compiler specific and using them in
big projects tends to be difficult.

But I was thinking (suprisingly enough) about gcc2xml being used
as an optional support for automated registering of things into mirror,
on those platforms where it is available.

>
> Once we have reflection, we need a way to deal with fields in a generic
> manner, whatever their type: int, vector<int>, vector< vector<int> > etc.
> One solution is to reflect the structure of the field's type as well: make
> the field class contain a pointer to a polymorphic type object, from which
> one derives int_type, a vector_type - which contains in turn a pointer to
> the element's type - etc. Pattern freaks will call it a composite ;-)
>
> The next step is multimethods. Once we have them we can write code like
> this:
>
>  // using BS's proposed syntax in D&E
>  void process_type(virtual type&, virtual processor&, void*);
>
>  void process(instance i, processor& p)
>    for each field (i)
>      process_type(*field->type, p, field->address(i))
>
>  class text_dumper : public processor { ... };
>
>  void process_type(virtual int_type& t,
>    virtual text_processor& p, char* pv) {
>    p << *reinterpret_cast<int*>(pv);
>  }
>
>  void process_type(virtual vector_type& t,
>    virtual text_processor& p, char* pv) {
>    p.indent();
>    char *iter = t.begin(pv), last = t.end(pv);
>    while (iter != last) {
>      process_type(t.element_type, p, iter);
>      t.forward(iter);
>    }
>    p.outdent();
>  }
>
> What do you think of the idea?

Mirror provides class and class instance *traversals*, which
"guide" custom user-defined generic visitors through the structure
of a class and optionally also allow to work with instances
of that class in a generic way.

Generaly the traversal calls the visitor's member functions
like enter_type, leave_type, enter_base_classes, leave_base_classes,
enter_attributes, leave_attributes, etc. depending on the
reflected class' declaration, with appropriate arguments.

The traversals can also provide the visitors with x-path-like ;)
meta-paths that can give insight about the context in
which the visited base_class, attribute, ... etc is visited.

Another way how to work with member attributes, base classes, etc.
is to use the algorithms like for_each or the iterators
provided by mirror.

This features are unfortunately still undocumented,
there are however several examples showing how
to use them included in Mirror.

>
> Jean-Louis

Best
________________
::matus_chochlik