"Rob Stewart" wrote: ________________________________________________________
6. Would it be possible to have other qualifiers, e.g.: "more_than_half_of"
if (more_than_half_of(a) >= any_of(b)) ...
or more complex versions like:
more_than(10).items_of(a) >= ... more_than(30.1).percents_of(a) == ...
less_than(2).items_of(a) >= ... less_than(95).percents_of(a) == ...
between(1, 5).items_of(a) >= ... between(10.5, 20.0).percents_of(a) == ....
Those are possible but are they sufficiently useful? Do you think they would be used enough to justify creating/documenting them?
IMO yes. Relational databases are almost all such calculations, for example.
Comparison between two "mores" would be disabled.
Why?
Because if (more_than_half_of(a) >= more_than_half_of(b)) ... doesn't make sense. ________________________________________________________
7. Will it be possible to use other predicates than
, <=, etc in following form:
if ( is_true_that(all_of(a), a_binary_functor, one_of(b)) ) ...
where the functor could be lambda:
if (is_true_that(all_of(a), _1 >= _2, one_of(b)) ....
It feels more natural than the asymetric "do_comparison".
I agree with the asymmetry of do_comparison(), but is it necessary to provide the additional predicate support?
Yes. Forcing user to define == etc operators doesn't make good design and there could be many, many possible predicates for single class.
Reasoning over the result of using none_of() with a user-defined predicate gets quite difficult when compared against an all_of() or other junction/multivalue objects. Doing so against a single value is much easier.
Yes but the documentation should say what combinations are potentially dangerous.
I think "evaluate" is better than "is_true_that:"
if (evaluate(all_of(a), _1 >= _2, one_of(b))) ...
People who also code in scripting languages with an "eval" function would get confused. ________________________________________________________
if (evaluate(all_of(a).where(filter1) , _1 >= _2 , one_of(b).where(filter2))) ...
This may be also useful. Either specific filters for each side, or one common, or both or one or none.
Nevertheless, the question arises whether all of this is warranted. Indeed, if we support iterator pairs in addition to ranges, there are other libraries that one can employ to do the filtering, so this one doesn't need to.
The filters could be lambdas. Result syntax could be smaller and easier to read then with another object (a filtering iterator). /Pavel