From: Rob Stewart (stewart_at_[hidden])
Date: 2005-08-02 20:23:44
From: "Pavel Vozenilek" <pavel_vozenilek_at_[hidden]>
> "Rob Stewart" wrote:
> >> Comparison between two "mores" would be
> >> disabled.
> > Why?
> 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
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
> > 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))
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_at_[hidden] Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;