----- Original Message ----- 
From: "Jeff Garland" <jeff@[...].com> 
To: <boost@[...].org> 
Sent: Tuesday, May 18, 2004 9:24 AM
Subject: Re: [boost] Ranged type mini-library submission


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

I should not have made such a sweeping statement.

>  And yet I see it done sucessfully all the time in modern C++.

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.

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

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

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

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.

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

I stand corrected, I should have said all parameterizations.

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

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.

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

Christopher Diggins
http://www.cdiggins.com
http://www.heron-language.com

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