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