From: "Pavel Vozenilek" <pavel_vozenilek@hotmail.com>
"Rob Stewart" wrote:
________________________________________________________
if ( is_true_that(all_of(a), a_binary_functor, one_of(b)) ) ...
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.
No, the (2) should be true if any value from 'a' cannot be equaled to some single value from 'b'.
I can't parse that well enough, but let's look at your example and compare.
This would make it symetrical to (1).
Say: a = green, blue, blue b = blue, red
none_of(a) == any_of(b) is false because there is blue (even 2 of them) from 'a' that match something in 'b'
Agreed.
any_of(a) == none_of(b) is false because there are two different cases when blue from 'a' is in 'b'.
I disagree. One of the values in a, green, is equal to none of the values in b, so the result is true.
Not because 'b' lacks 2 blues.
Agreed.
IOW any_of() should care about cardinality.
Nope. none_of() cares about cardinality.
For the any_of(s1) == one_of(s2) one_of(s2) == any_of(s1)
I think the "one_of" should read as "exactly_one_and_only_one_of"
Agreed.
and "any_of" as "any_individual_item_of"
Agreed.
This should restore the symetry.
Disagree. Consider: any_of(green, blue, red) == one_of(blue, red) green != one_of(blue, red) blue == one_of(blue, red) red == one_of(blue, red) result: true one_of(blue, red) == any_of(green, blue, red) blue == any_of(green, blue, red) red == any_of(green, blue, red) result: false
This is my understanding how these qualifiers should be implemented and thought about. The other interpretation didn't occured to me but perhaps I am still missing the 'aha!' moment.
Perhaps I've enabled your epiphany.
I didn't study the implementation deep enough (I would need to step through) but it should be symetrical.
That was my first thought, but I've come around to seeing the asymmetry. As David Abrahams pointed out, the semantics should follow English rather than mathematics. That is, they should behave the way they sound.
Perhaps we should consider a functional style:
if (compare(all_of(a), one_of(b), _1 >= _2))
That would be
if (compare(_1 >= _2, all_of(a), one_of(b)))
woudn't it?
Either one would work. A more infix-like notation is probably better: if (compare(all_of(a), _1 >= _2, one_of(b)))
________________________________________________________
if (evaluate(all_of(a).where(filter1) , _1 >= _2 , one_of(b).where(filter2))) ...
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.
IMO syntax should decide what to use.
If filter iterator is as easy to use as hypothetical embedded filter than I am all for for it.
OK
Expression that could be written on single line it is much prefered to alternatives:
I don't agree with that criteria at all. It is easy to create single lines that are ridiculously complex and difficult to read.
vector<int> a; set<int> b;
if ( is_true_that(any_of(a), _1 * 2 >= _2, all_of(b)).where(_1 >= 0 && _2 > 10) ) {
is still somehow readable (as long as the filter is simple).
That would be more readable if there were a type X that holds a filtered multivalue: X lhs(any_of(a).where(_1 >= 0 && _2 > 10)); X rhs(all_of(b).where(_1 >= 0 && _2 > 10)); if (compare(lhs, _1 * 2 >= _2, rhs)) ... I don't think the .where() clause you've suggested should be considered to operate on the two multivalues. It is operating on the result of is_true_that from the syntax, so it is nonsensical. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;