From: "Pavel Vozenilek" <pavel_vozenilek@hotmail.com>
"Rob Stewart" wrote:
Comparison between two "mores" would be disabled.
Why?
Because if (more_than_half_of(a) >= more_than_half_of(b)) ... doesn't make sense.
It does to me. Suppose a is the set of female students and b the male students. Further suppose that >= compares grades. Then the expression asks whether more than half of the girls got grades at least as high as more than half of the boys.
________________________________________________________
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.
If you allow that, then symmetry cannot be guarranteed. There's already a question as to whether the operators must be symmetrical. I've posited that asymmetry will lead to confusion, but many comparisons sound asymmetrical. Consider these two expressions: none_of(a) == any_of(b) // 1 any_of(a) == none_of(b) // 2 1. Sounds like it should be true if none of the values in a equal any value in b. 2. Sounds like it should be true if any of the values in a equals none of the values in b. Florian's notion of these operators, derived from Perl, is that they are not symmetrical. To make expressions like 1 and 2 symmetrical, I've taken to swapping arguments depending upon the combination of types, which means I'm forcing the symmetry. Maybe I'm just off the mark and they should be allowed to be asymmetrical.
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.
Dangerous? Inefficient or useless, maybe, but 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.
I was actually thinking of that when I wrote it. However, eval usually has some value, though I think it is really just a status code, not related to the expression being evaluated. Perhaps we should consider a functional style: if (compare(all_of(a), one_of(b), _1 >= _2)) or if (compare(all_of(a), _1 >= _2, one_of(b)))
________________________________________________________
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.
For a common filter, you can just reuse it.
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).
That may be true, but I'm concerned about duplicating functionality and, thus, limiting flexibility. I guess we just need to be sure that this library interoperates easily with filters created using the facilities of the other libraries. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;