Re: [Describe] My review of Describe

From: Peter Dimov (pdimov_at_[hidden])
Date: 2021-03-05 19:11:25

Andrzej Krzemienski wrote:
> pt., 5 mar 2021 o 09:00 Julien Blanc via Boost <boost_at_[hidden]>
> napisał(a):
...
> > It looks that there's a mix of apples and orange in this enum. Some
> > values acts as they will include more data in the results, some on the
> > contrary will filter, and some will change completely the type of the
> > members enumerated. This is not obvious when reading the
> > documentation, and there's just nothing in the name of the enumerated
> > values that will hints the user about what it really does.
> >
> > This design issue is my main motivation for the conditional acceptance
> > of the library: i think it should not be accepted until this part is
> > fixed.
> >
> 
> I agree with the observation. My explanation for it (I do not know the real
> motivation, just saying as a reviewer) is that it is driven by use cases.

That is correct. I already gave a partial answer in
https://lists.boost.org/Archives/boost/2021/03/250949.php, but that may
have been too short.

The majority of use cases deal with nonstatic data members, so the library
makes this the default (you don't need to supply any modifier in order to
get the nonstatic data members.)

In contrast, there's no good default for accessibility. Some use cases need
just the public members, some need public+protected, some need all, some
need public+protected and separately the private ones, and so on.

The cases where one needs the static members are rarer. And since the type
of the pointer returned in the descriptor differs between static and nonstatic,
one typically doesn't need both returned at the same time.

In the rarer still cases where one does want both static and nonstatic members
at the same time, there's always the option of mp_append-ing the two
descriptor lists. So the design approach here is to keep the more common cases
short, while leaving advanced uses more complex.

There are many ways one can redesign the modifiers, and I already went through
most of them. This is what I have settled on.

I do accept the feedback that this needs better documentation, and perhaps
comments in modifiers.hpp for the people who look there first (don't we all).