[PFR] The user's perspective

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[PFR] The user's perspective

Boost - Dev mailing list
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;

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [PFR] The user's perspective

Boost - Dev mailing list
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 <[hidden email]> 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).

>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [PFR] The user's perspective

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [PFR] The user's perspective

Boost - Dev mailing list

> On Sep 30, 2020, at 7:57 AM, Peter Dimov via Boost <[hidden email]> 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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [PFR] The user's perspective

Boost - Dev mailing list
Hadriel Kaplan wrote:

> 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>.)


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [PFR] The user's perspective

Boost - Dev mailing list

>> 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.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PFR] The user's perspective

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
śr., 30 wrz 2020 o 13:57 Peter Dimov <[hidden email]> 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;

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost