Re: [boost] [review][constrained_value] Review of Constrained ValueLibrary begins today

Subject: Re: [boost] [review][constrained_value] Review of Constrained ValueLibrary begins today
From: Robert Kawulak (robert.kawulak_at_[hidden])
Date: 2008-12-07 20:50:40

> From: Stjepan Rajko

I think I get your idea. However, it is still a fresh mental model and I'm not
confident about all the hidden problems that may be involved. Anyway, here are a
few loose comments of mine.

> The above treatment covers the current behavior of the library, allows
> dealing with issues such as the floating point case

Actually, I would see something different as a perfect solution to the FP
problem. If an "exact floating point" type could be provided (out of scope of
this library), being a wrapper for float/double and making sure that its
underlying value is always truncated, you could perform comparisons (and all the
other operations) that are repeatable, without the possibility that a comparison
that once succeeded will later fail. Does it sound sensible?

And the "exact floating point" could be implemented as a monitored value that
would truncate the value on assignment... Isn't it getting crazy? :D

>  AFAICT, It requires no changes to the
> implementation.

Not exactly:
- there are asserts checking for the invariant, which then should be removed,
- given the modified set of concepts and assumptions, the current names in the
code do not necessarily fit the purposes (e.g., constraint is not constraint
anymore, it is the trigger of the monitor callback, which in turn is the former
error policy).

I also think that it should be analysed whether the current design really fits
monitored values in an optimal way. The implementation seems optimal for
constrained values, which doesn't have to be the case for monitored values. And
the other way round -- maybe a monitored value wouldn't be a best choice for
implementation of constrained value?

I think the idea of monitored values as the generalisation of constrained values
seems reasonable and elegant. Unfortunately I doubt I would have time and
resources to transform Constrained Value library into Monitored Value library
(this library already consumes more of my free time than I have :P). However, I
think that if such library is created in the future, then Constrained Value
library may be re-implemented in terms of it (as an extension).

One more thought -- monitored value may be actually a case of even more general
idea, something similar to transparent proxy in .Net, or at least something that
could be called a "universal wrapper". This wrapper would allow to define
callbacks invoked every time the value is being set (as in monitored value) and
get. (I think somebody might have already been discussing this idea with me, but
it would be a long time ago and I can't remember.)

Best regards,
Robert