Re: [boost] [review][constrained_value] Bounded value

Subject: Re: [boost] [review][constrained_value] Bounded value
From: Edward Diener (eldiener_at_[hidden])
Date: 2008-12-03 11:01:36

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.