Re: [boost] [constrained_value] Constrained Value review results

Subject: Re: [boost] [constrained_value] Constrained Value review results
From: Gordon Woodhull (gordon_at_[hidden])
Date: 2010-09-14 02:44:13

Hi Robert,

> You want to say literally all? I mean, some of the points were rather suggestions or minor requests (at least I felt so) or had no clear conclusion, e.g. "serialization" or "rename bounded_int", to name a few.

I meant to include in this section only changes that you agreed to.  If there are items which you now disagree with, or which still require substantial debate or effort, then sure, they should not be conditions on acceptance.

Not everything which should be done has to be done before release.  There will be further maintenance afterward.  However, I don't think it's just the "major" issues which should be addressed.  There is also value in solidifying the interface before release.

I don't think it will be too onerous to implement most of these - see below. 

> For some of them I don't see how I could address them in documentation or why should they be crucial for final acceptance (don't get me wrong - I'm open for suggestions, but for instance if I were to add all the examples suggested by people to the docs, it would become too bloated and out of topic.

Not all examples have to go into the documentation.  People will also look in the examples directory for hints how to do something.

> A software maintainer can't do everything to please anybody but has to choose which requests to implement and which not to).

Which is why I tried to put only the items on which you agreed in this section.

> To conclude - I don't feel section 3 contains only major issues, so should all of them be crucial for acceptance?

So let's walk through the items and decide which need to be addressed before release.

> Floating point

Here's it's possible to specify a constraint outside of the library, and it seems that for x87 it is going to need to make sure the bounds have made a round-trip to memory (unless there is a more efficient trick).  So there is no modification needed here, unless a float-specific API will be provided.

Hopefully this can happen quickly, maybe even before release, but it is not your responsibility.

> NaN

Likewise.

> Substitutability with the underlying type

Document why this is not possible, drawing from your very cogent explanations on the list.

> Constraints not copied when operators used

Same.

> Constrained strings

It shouldn't be difficult to provide an example of validation against a set of strings, and perhaps a regex example.  To reduce effort, these could be kept as examples until the classes mature enough to be included in the library proper.

> Bounding on only one side

If this requires interface changes, it would be better to do this before release.  If it just requires more classes and no changes to those existing, then it could wait.

This seems like a very useful feature; on the other hand it's not part of the essential design of the library, really just more predicates and convenience classes.  I'd encourage you to implement it soon to maximize your audience.

A rough draft could go into the examples.

> Recoverable error policy - error policy changing the value

The action item here is to clearly call it a "recoverable error policy" to explain why it can change the member value.  There was also some interesting design discussion here, but not requiring action.

> Serialization

Probably not required for release, but pretty important.

> Neal Becker requested support for serialization.  RK agreed this is worth looking into and pointed out a couple of difficulties.  One, a way to not serialize empty (or static) policies is needed.  Two, non-default constructible types such as odd_number might require use of load_construct_data() / save_construct_data() instead of serialize().

These don't seem to be insuperable difficulties, but perhaps they will require more time to resolve.

> Rename bounded_int

The unique characteristic of this class is not that it's bounded or an int, but that the bounds are specified at compile time.  I think you agreed that a name change is needed, and if so, it should go in before release.  I know that naming classes can be frustrating, but just because you don't like the names compile_time_bounded or static_bounded does not mean that change isn't necessary.

> test: sizeof static constrained types == sizeof underlying type

Essential!  (and not just because it's one of mine!)

> Specify static bounds as open<0>, closed<100> for bounded<> and bounded_int<>

Maybe wishful thinking on my part.  You said you'd look into this.  The boolean open/closed flags are definitely confusing.

> Some default constructions may throw

Defaulted values are probably out of scope, but a warning in the documentation about odd_int and its ilk is a good idea.

> Examples
> 
> * an example showing how to create a constrained class by derivation and/or containment which adds/removes methods from the constrained value interface 

You didn't want to do this, so maybe it belongs in the unresolved debates section.

> * a date example where changing the month affects the bounds for the day.

You said you'd try this.  Again, it doesn't necessarily need to complicate the documentation, and it doesn't need to be perfect if it's just an example.  (E.g. it could comment that it doesn't support leap years. ;-)  Maybe it doesn't need to go in before release, but as Vicente pointed out, for anyone thinking about dates, this is the first thing that will come to mind.

> * example of static bounding on only one side 

At worst this could be an example with INT_MAX/INT_MIN.  An important feature which belongs in the documentation.

> * example of bounds calculated at runtime by a function ("runtime dynamic bounding")

This just seems to be a more complicated constraint which has extra data or which calls into something else that has state (like a timer).  Vicente might be able to provide a simple example.  Maybe not necessary for release.

> * example of constraints with static members - allows shared mutable constraints with no overhead per instance.

I think may have been one of mine - not necessary for release but an interesting curiosity.  

Another related idea which came up outside the review was the idea of constrained_container, where the constraint is shared by all elements, but I ran into trouble with the obvious implementation using proxy constrained_values of reference type.

> Tests!

Deadly essential for release.

In summary, these are mostly ideas which you agreed are important, so to avoid redundant questions on the list, please document and/or provide (imperfect) examples.  

Yes it is some work, but IMO one purpose of the review is to show that you are willing to maintain and respond to requests.

Cheers,
Gordon