On Tue, 18 May 2004 00:17:40 -0400, christopher diggins wrote
>  I detect some frustration, I mean you no disrespect, I hold your 
>  work and comments in very high esteem.

No frustration, sorry it transmitted that way.  Your statement was very
broad, and implied that there are 'many problems' inheriting a template
parameter.  And yet I see it done sucessfully all the time in modern C++. 
Since I'm basically unaware of 'problems' with this approach your statement
hit me much like the ever recurring programming guildeline: "Don't use
multiple inheritance because it might create problems".  Complete bunk that
needs to be corrected...

>  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.  

>  The problem with parameter inheritance, as least in this case, is 
>  that it surprises programmers by causing an object to have an inconsistent
>  interface.  

This is really a matter of documentation.  If I get used to calling 
  mytype1::get_constraints().max() 
to find the max then I'm going to use my handy code editor to propagate this
code around.  As soon as I hit mytype2 that doesn't have constraints with a
max  function I'll be just as stumped as if mytype2::max didn't compile.  Then
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.

>  Most programmers when confronted with code such as 
>  mytype::max() expect that max will be available for all instances of 
>  mytype. 

I assume here mytype refers to the constrained_value template?  Because for a
given user type generated from this template mytype::max will be available for
all instances.

>  On the other hand, mytype::get_constraints().max() is 
>  generally understood to not always be readily available in a 
>  parameterized type.

Really?  Let's say I've never seen the documentation for constrained_value and
I'm just reading some code I didn't write.  For me, I have to think for an
extra nano-second ( little joke :) about the meaning of this code:

 mytype::get_constraints().max()

I'm thinking let's see, a static function that returns an object with a max
function.  As opposed to just -- yeah, get the max.

 mytype::max()

>  I don't see how the advantage of the shorthand justifies the case for
>  parameter inheritance here.

I'll turn it around the other way -- I don't see how the 'longhand' makes the
interface any clearer.  The interface still needs a description the user can
understand.  In any highly flexible template design this is always more
difficult.  

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 ;-)

Jeff
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost