[FPR] Some feedback

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

[FPR] Some feedback

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

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

Re: [FPR] Some feedback

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


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

Re: [FPR] Some feedback

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list


> On Oct 2, 2020, at 6:42 PM, Andrzej Krzemienski via Boost <[hidden email]> 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


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

Re: [FPR] Some feedback

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sat, Oct 3, 2020, 01:43 Andrzej Krzemienski via Boost <
[hidden email]> 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
>

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