
Boost : 
Subject: Re: [boost] [review][constrained_value] Bounded value
From: Edward Diener (eldiener_at_[hidden])
Date: 20081203 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 twoelement 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 multibound concept, in which case the current bounded object concept is just a subset of the multibound 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 subrange of the allowed set.
I am hoping that you see a use for multibounds constraints without the
need to provide predicates. A predicate is much more flexible but a
nonpredictae syntax for multibound constraints can be much easier and
quicker for the end user to specify.
>
> If you don't care about efficiency or want to use
> dynamicallyadjustable 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
multibound constraint is a static constraint like your current bounded
constraint.
>
> The builtin support for such multirange 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 multibound constraints and implement
your current single bound constraint as a subset of multibound
constraints with a single bound. Thus you would provide greater
flexibility while maintaining what you already have done.
The idea of a multibound 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
multibounded 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk