Re: [FPR] Some feedback

From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2020-10-03 10:36:10

On Sat, Oct 3, 2020, 01:43 Andrzej Krzemienski via Boost <
boost_at_[hidden]> wrote:

> Hi Everyone,
> Not sure if I will be able to provide a decent review, so I wanted to at
> least share some thoughts.
>
> 1. Do not use "reflection" in the library name. "Reflection" means "any
> information I could ever need about any part of the program". In
> particular, people might expect that you will be able to give the class
> member names; you cannot, and they will call it a bug in the library,
> because it implied that it would be able to do this, as this is what you
> expect from reflection.
>
> What this library does is to give a tuple-like access to class members
> (plus a number of things atop of this). Maybe it should be called
> Tuple-like Element Access (TEA)?
>

Good idea. But I'd rather avoid change of abbreviation. How about "Precise
and Flat Representation"

2. The library can only provide tuple-like access to classes that meet
> certain criteria, but these criteria are not obvious. Calling it an
> aggregate-initializable struct is not good enough:
>
> ```
> struct B {};
> struct D : B {
>   int i, j;
> };
> ```
>
> Struct D is an aggregate (in C++20) and can be aggregate-initialized with
> three elements, but will not work with the library. I suggest you list
> requirements and give them a name. Bjarne Stroustrup called something
> similar a "flat":
> https://www.youtube.com/watch?v=ERzENfQ51Ck&feature=youtu.be&t=376
> but I am not sure if this is the right one. Maybe "simple aggregate".
>

Good point. "Non-derived aggregate"?

This would help users prepare for what to expect. I do not know if this can
> be statically tested (like if a class has any base) but this does not
> matter as long as the requirements are listed in the docs. This concept is
> core to the library.
>
> 3. Does this library bring any value for arrays? It works for arrays, but
> arrays already provide index-based element access.
>

Not much. But arrays could be part of the aggregate... and it makes the
things hairy.

4. Thank you for writing and sharing this library. I really like it.
>

Thanks for the interest!

Regards,
> &rzej;
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>