On Tue, 18 May 2004 09:59:05 -0400, christopher diggins wrote
It definitely is a powerful technique that I have used often. I am very hesitant about using it in libraries destined for public consumption when there exist alternatives which are more intuitive for naive programmers.
Well, I submit that if that attitude prevailed then the standard library as we know it would not exist. But I'm falling into the arguing in generalities trap...
I just changed the code by removing the public constraints typedef and adding a static function get_constraints() so that it can be invoked using instances of an object as well.
Well, ok, but I still don't like it.
I respect that, but my concern in this instance is whether Joe Average programmer will like it and understand it quickly.
Who is this Joe Average anyway -- is he related to Joe Sixpack ;-)
I start looking at the docs and code to figure out what went wrong. But then I shouldn't expect a type with a name like 'divisible_by_four' to necessarily have a min/max interface.
I don't doubt that someone of your level of expertise would figure things out quickly, but my concern is with the lowest common denominator of experience. We are writing a library for the public, not for ourselves.
Why would it be easier for me or Joe Sixpack to understand your variation of the interface? You state this as though it were fact, but what I'm saying is that for me your variation is harder to understand. I think Rob Stewart agrees. I refuse to assume that I know what Joe Sixpack can understand, but looking at this typedef: typedef constrained_value<policies::divisible_integer<2> > even_integer; I wouldn't even think to try and call even_integer::max, while with this one: typedef constrained_value<policies::ranged_integer<0,2> > zero_to_two; it makes perfect sense.
An interface, as I am using the term here, is the set of public functions and public fields. An inteface for a parameterized type is generally understood to have functions or fields whose type is variant on a parameter. It is not generally understood or assumed that functions may or may not exist in a parameterized type.
I think I finally understand your concern. But, the fact is, the entire design can be assailed on this point. As soon as I throw an exception when the value is out of range instead of logging an error the 'naive user' (the one that didn't read the documentation) will be in debug mode. And Joe didn't even get told by the compiler. The point is that the final generated type is the point of behavior documentation that most users see -- not the constrained_value template itself. I also think you dare to presume an awful lot about what your fellow programmers can and can't understand.
One last point. By inheriting from the policy, we can both have our way. You can specilize your constraint policy to have a public method 'get_contraints' that returns an object and I can have my min/max. Now that's power ;-)
Your technique is most definitely more powerful but I am still concerned for naive users.
Naive and power users will read the tutorial first if something doesn't work. I suggest we educate the naive users by writing good documentation and examples rather than constraining the design. Jeff