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)? 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". 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. 4. Thank you for writing and sharing this library. I really like it. Regards, &rzej;
Andrzej Krzemienski wrote:
2. The library can only provide tuple-like access to classes that meet certain criteria, but these criteria are not obvious.
In particular, how base classes are handled is not apparent from the documentation (unless I missed it.) From the repo issues, I can see that a (non-empty) base class is treated as a member by the precise API.
On Oct 2, 2020, at 6:42 PM, Andrzej Krzemienski via Boost <boost@lists.boost.org> wrote:
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)?
Macro-less Aggregate Getter, Iterator and Comparator by Generally Emulating Tuples (MAGIC-GET) or... Minimal Aggregate General Introspection Component for Grafting Elements to Tuples (MAGIC-GET) -hadriel
On Sat, Oct 3, 2020, 01:43 Andrzej Krzemienski via Boost < boost@lists.boost.org> 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
participants (4)
-
Andrzej Krzemienski -
Antony Polukhin -
Hadriel Kaplan -
Peter Dimov