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.

Robert Kawulak wrote:

...

From: Edward Diener

...

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.

Predicates are the central part of the design of the library and this is rather not going to change. Even if the library would provide support for multi-bounded objects, the constraint would be implemented as a predicate, just like it is in the case of bounded objects right now.

I meant that the user should not have to specify his own predicate in order to get multi-bounded objects just as the user does not have to specify his own predicate to get bounded objects.

BTW, I don't think that the syntax for providing an arbitrary number of bounds at compile time would be attractive, not to say easy for the users... At least not until we have compilers supporting variadic templates.

I agree completely. I realized that without variadic templates multi-bounded objects would probably need a constructor taking the bounds rather than as template parameters.

...

The idea of a multi-bounded constraint is that the set of valid values should be able to encompass any value for that type

I really have no idea what you wanted to say here...

Only that the notation for a multi-bounded constraint should allow any number of single bounds.