Hi Everyone, I am now trying to study the PFR library, and wanted to share some thoughts and see what others think. First, thanks Antony for writing and sharing this library. I have watched your video on it, read the docs, and I find it amazing that you were able to implement such reflection in C++. This is in the spirit of the good old Boost libraries that just implemented magic. Now, to the critique. From looking at the docs and the videos, I inferred (perhaps incorrectly) that the library was created in this order: "We can do type introspection for aggregates, so let's see to what extent we can provide an interface of a reflection library." The extent is quite amazing (e.g., I really appreciate having pfr::less<> out of the box), but to the end user, I think, the library will still appear as incomplete. That is, when my type is an aggregate it will work, but when I need to add a convenience constructor it will immediately break, and I will have to switch to another library, like Peter's Describe ( https://github.com/pdimov/describe/tree/master). With Describe, I will have to type more, but I have a guarantee of a uniform experience both for aggregates and for other types. And given that I have to use Describe at some point there may be no point in also keeping PFR and forcing on myself and my colleagues two different interfaces. Describe is not a perfect solution either, because for aggregates I have to declare the mapping, which is unnecessary as PFR has demonstrated. My ideal solution would be if these two libraries (PFR and Describe) would be merged into one, so that: 1. They provide the same interface 2. A user can easily instruct the library: "this is an aggregate: figure out the mapping yourself". I am sorry if it sounds arrogant: people are devoting their private time to write and share a cool library, and all they hear back is "do more." But I thought it would also be unfair not to give this feedback. I am also not sure if the goals of the two libraries are compatible (e.g., Describe is also interested in giving names of the members) . I would be curious to see what the authors think about it. Regards, &rzej;
We've been using PFR on a huge codebase for two years now. In many cases it's functionality is enough. For example, we're using PFR to get data from database: struct OrderInfo{unsigned id; string client, merchant; decimal price; }; auto order = db.Execute(statement).As<OrderInfo>(); Some other usecases for PFR: * SPIRIT like parsers - parsing directly into the user provided structure * Binary serializers and readers - to easily store/retrieve data from a local file * Generic code - move users from tuple and pair to aggregates to improve code readability and performance On Wed, Sep 30, 2020, 10:43 Andrzej Krzemienski <akrzemi1@gmail.com> wrote: ... My ideal solution would be if these two libraries (PFR and Describe) would be merged into one, so that: 1. They provide the same interface 2. A user can easily instruct the library: "this is an aggregate: figure out the mapping yourself". I'm in favour of ideal solution, but that should be separate from PFR. There's quite a lot of projects where codegen is used instead of macro registration, and for those projects PFR is fine but Describe is doubtful (even though it is better that many inhouse codegen solutions).
Andrzej Krzemienski wrote:
My ideal solution would be if these two libraries (PFR and Describe) would be merged into one, so that: 1. They provide the same interface 2. A user can easily instruct the library: "this is an aggregate: figure out the mapping yourself".
The two libraries don't really overlap, even though they enable the same functionality. Describe gives you member names (and other things such as member functions, inherited members and base classes), but it requires explicit registration; PFR only gives you references to the data members, but works without registration. There's no reasonable way for the two to be merged.
On Sep 30, 2020, at 7:57 AM, Peter Dimov via Boost <boost@lists.boost.org> wrote:
Andrzej Krzemienski wrote:
My ideal solution would be if these two libraries (PFR and Describe) would be merged into one, so that: 1. They provide the same interface 2. A user can easily instruct the library: "this is an aggregate: figure out the mapping yourself".
The two libraries don't really overlap, even though they enable the same functionality. Describe gives you member names (and other things such as member functions, inherited members and base classes), but it requires explicit registration; PFR only gives you references to the data members, but works without registration. There's no reasonable way for the two to be merged.
I don’t think he means “become one” - I think he means since Describe feels almost like a superset of PFR, but PFR is simpler/easier for pure aggregates due to no registration, perhaps Describe could copy the API of PFR for the overlap. That way changing your code from using PFR to Describe when your type is no longer an aggregate, could be made easier. (The reverse direction would never be simple) I have no idea if such a thing is possible or practical, but it would be cool. :) -hadriel
perhaps Describe could copy the API of PFR for the overlap.
I don't see how. Describe gives you a typelist describing the type, at compile time; PFR gives you a tuple API (tuple_size and get<I>.) That's similar to what I have requested earlier: Using range-based for on enumerators directly. It is already possible to do on top of Describe and I'm pretty sure the pfr interface is too. So it is more about
providing a bit more and maybe in an optimized manner.
śr., 30 wrz 2020 o 13:57 Peter Dimov <pdimov@gmail.com> napisał(a):
Andrzej Krzemienski wrote:
My ideal solution would be if these two libraries (PFR and Describe) would be merged into one, so that: 1. They provide the same interface 2. A user can easily instruct the library: "this is an aggregate: figure out the mapping yourself".
The two libraries don't really overlap, even though they enable the same functionality. Describe gives you member names (and other things such as member functions, inherited members and base classes), but it requires explicit registration; PFR only gives you references to the data members, but works without registration. There's no reasonable way for the two to be merged.
Yes, I see what you are saying. I guess, it is just my use case. I need to provide a tuple-like access to structures, not necessarily as simple as aggregates. I want to do it in a way that requires as little of additional typing as possible. Now it looks like the only way to do that is to provide a third library on top that would delegate either to FPR or Describe as needed... Rgrds, &rzej;
participants (5)
-
Alexander Grund -
Andrzej Krzemienski -
Antony Polukhin -
Hadriel Kaplan -
Peter Dimov