Re: [boost] [OT][RFC] standardized compile-time reflection

Subject: Re: [boost] [OT][RFC] standardized compile-time reflection
From: Matus Chochlik (chochlik_at_[hidden])
Date: 2012-04-23 11:59:15

Hi,

On Mon, Apr 23, 2012 at 5:03 PM, Julien Nitard <julien.nitard_at_[hidden]> wrote:
>
> I am interested a lot in introspection in C++. I have been using
> another approach (and extended) boost.reflect.
>
> I'd like to participate in the effort. The document is rather lengthy
> though and I am not done reading (I've been away the past few days).

Nice to hear!

> Here are a few comments though:
>
> - Globally you start with the complex stuff. Yes what you did is very
> powerful and complete, but please consider the user point of view
> first.
> I am a user for reflection data and here is what I'd like to see when
> I am thinking about introspection in C++:
>
> #pragma reflect // generate metadata for the next language element
> sturct Reflected
> {
> Â  Â int a;
> Â  Â string b;
> Â  Â double c;
> };
>
> vector<Reflected> myData;
>
> CsvWriteHeader<Reflected>(myFile);
> for (auto& entry: myData)
> Â  Â CsvWriteLine(myFile, entry);
>
>
> All the meta programming is very clever but has (IMHO) a smaller
> target audience, it's the mean, not the purpose. I believe you should
> start with the purpose then explain how you did it.
> So as a first piece of advice, I'd show how to reflect a POD (only
> data members) then a class (methods, static members) then a template
> and a template instance (if that is possible didn't check yet).

I didn't want the paper to be too long and boring but,
you're right I'll add some such examples of usage.

One of the design goals is "completeness" i.e. to provide as much meta-data
as possible (to a reasonable level) to accommodate also the more obscure
use cases for reflection not only the most obvious ones (like
serialization, etc.)
which might make it "scary" for newcomers.

On the other hand I expect that the basic meta-data provided
by the compiler (as described by the paper) would be wrapped
by some higher-level libraries (like Mirror) that would be more user friendly.
This library/libraries would also be part of the standard. Others could
be implemented by 3rd parties.

>
>
> Â - Â I think you are neglecting the aspect on how the user can choose
> the types that are going to be reflected. I believe not all types
> should have their metadata generated, at least to save on compile time
> on large projects. The way I did it in my preprocessor was using a
> pragma directive but it was much simpler than Mirror since it was only
> intended for classes. There migth be other ways, though, but it should
> be made more explicit. If reflection makes it into the standard, there
> shouldn't be any tools to generate the metadata besides the compiler.
> For the standard library, I guess that including a given header or
> using reflect operator would bring in the metadata.

Actually, this is one of my primary concerns. I also think that the way
to go is not to reflect everything automatically, but to let the user
to (somehow) choose what should be reflected. But i think that
the process of "marking" namespaces, classes, etc. that should
be reflected, should be decoupled from the declaration of the namespace,
class, etc. because that would allow greater flexibility and also
would allow to cherry-pick, what parts of 3rd-party libraries should be
reflected in concrete applications based on their needs.

This is mentioned in the "Unresloved issues" section.

>
>
> - I am not sure whether the "reflect" operator is a good idea. First
> I'd change the name to mirror since reflection is usually employed
> when the objects know their own metadata, which is not the case here.

Personally I don't have anything against "mirror" I just didn't want
to put any shameless plugs there :) since Mirror is also the name of the library
that I'm working on. But I'll go with anything the community here suggests
or the Committee decides (if the proposal manages to go that far).

> Then i guess that the operator should return a type, not a value, for
> easier use in metaprograms.
>
> #pragma mirror // (or reflect)
> struct S { … };

As already said above, I would like this to be decoupled. For example:

---
lib-header.hpp:
---
namespace ns1 {
struct S1 { ... };
struct S2 { ... };
struct S3 { ... };
...
struct Sn { ... };
} // namespace ns1
---
app.cpp:
---
#include <lib-header.hpp>
// I just want S1, S23 and S42, not the whole library
#pragma-or-whatever mirror ns1::S1 ns1::S23 ns1::S42
... use the metadata provided by reflection here ...
>
> // defines a function that only accepted mirrored types
> template <class T>
> typename std::enable_if<mirror(T)::is_defined>::type
> f(T& t);
>
The is_metaobject<mirror(T)> type-trait that is proposed in the paper
should probably suffice and be implemented with a compiler intrinsic
like the other type traits..
>
> If a new operator is too much, then a lot could be achieved using only
> template specialization, but that would not work with namespaces
> easily.
> ( mirror<T>::is_defined ...). It's probably Worth mentioning in a proposition.
>
This is discussed in the "Reflection" section:
- The operator would be "nicer" and more convenient but has a potential
to break a lot of existing code.
- A (set of) reflection function(s) is not so "powerful" and "nice" but
should not break anything.
> - I guess the "mp" namespace is something in the lines boost::mpl but
> there's no such thing in the standard yet. You should try to show use
> cases that are more accessible to main stream programmers and that
> show useful features without having to write and document a full page
> of code.
The paper does not suggest that the Mirror library should be copied
verbatim into the standard. But as already said above I expect that
there would be such library to make the usage of the meta-data
provided by the compiler easier.
There actually could be multiple libraries like in the Mirror utilities
ranging from compile-time functional-style reflective meta-programming
to a dynamically loadable run-time reflection.
I definitely plan to update/rewrite Mirror et. al. to use the meta-data
once the specification if "polished".
>
> Everything is still a bit messy, sorry if I said anything stupid, it's
> a bit late here. Despite all the criticism, please be assured that I
> appeciate the huge effort you've been pulling, I have focused on what
> I think could be improved ;). I'll make more comments later on, when
> I'll have digested your library a bit better.
Thank you for your feedback. It is much appreciated and I look forward
to any other suggestions you might have.
Best,
Matus