Robert Kawulak wrote:
Hi Edward,
2008/12/3 Edward Diener
I believe the bounded objects are actually a subset of a larger concept, which is the set of valid values for an object. Ideally what one could have is a set of bounded values which define the valid values. Each member of the set could be a pair ( or two-element tuple ) defining a lower and upper value inclusive, and of course a single value in the set would have its lower and upper value be the same. In this way one could define, as an example, a constrained object whose integer value could be between 0 and 20 and between 50 and 70. Currently the bounded object concept only allows one "bounds". With the larger concept I mention, a bounded object can have any number of bounds. While the single bounds bounded object can still be supported, I would like to see the constrained value library implement a multi-bound concept, in which case the current bounded object concept is just a subset of the multi-bound with a single bound.
What you ask for can be easily achieved using the current implementation. All you have to do is to define a constraint that encapsulates several within_bounds predicates, each one responsible for one sub-range of the allowed set.
I am hoping that you see a use for multi-bounds constraints without the need to provide predicates. A predicate is much more flexible but a non-predictae syntax for multi-bound constraints can be much easier and quicker for the end user to specify.
If you don't care about efficiency or want to use dynamically-adjustable sets, the task is almost trivial - use boost::signal as the constraint type and provide a combiner that returns logical alternative of the results. Then add instances of within_bounds (or any other predicate) as slots of the signal.
This seems like an overly complicated usage of signals, but of course it works dynamically. A predicate can also work dynamically. My idea of a multi-bound constraint is a static constraint like your current bounded constraint.
The built-in support for such multi-range sets could be added to the library too, but I wonder if the use case is common enough and I should focus on this right now. Anyway, this shuold be easy to achieve anytime in the future with no modifications to the current implementation.
If you mean that your current functionality need not change, I agree. I am asking that you consider adding multi-bound constraints and implement your current single bound constraint as a subset of multi-bound constraints with a single bound. Thus you would provide greater flexibility while maintaining what you already have done. The idea of a multi-bound constraint is really the idea of a set of valid values for any type. In your current bounded constraint you are reducing that set of valid values to a single bound, which of course can be even just a single value if you like. That is valid, and perhaps the most common use case, but it is not very flexible IMO. The idea of a multi-bounded constraint is that the set of valid values should be able to encompass any value for that type and still be easy for the end user to denote. I know your current implementation is being reviewed and should not change while the review is ongoing so that reviewers will comment on what you have already done. I only ask that you consider my suggestion as a more thorough implementation on static constraint values for the future.