From: Pavel Vozenilek (pavel_vozenilek_at_[hidden])
Date: 2005-08-02 13:33:09
"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
IMO yes. Relational databases are almost
all such calculations, for example.
>> Comparison between two "mores" would be
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.
> 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).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk