SOURCE 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost