----- Original Message ----- 
From: "Jeff Garland" <jeff@[...].com> 
To: <boost@[...].org> 
Sent: Monday, May 17, 2004 10:02 PM
Subject: Re: [boost] Ranged type mini-library submission


>  On Mon, 17 May 2004 11:53:49 -0400, christopher diggins wrote
>  > You are completely correct about min and max. So I removed them. How
>  > about exposing the constraints_policy as a public typedef (I just
>  > posted a version which does this). This is perhaps a good
>  > compromise?
> 
>  No, not really.  I wanted to be able to ask the type it's min and max if
it is
>  a range type.  Now I suppose I can dig out the policy, but it's fairly
>  cumbersome in comparison to just calling mytype::max().
> 
>  > There are just so many problems that can arise from
>  > parameterized inheritance, I would like to avoid it if there is an
>  > acceptable alternative.
> 
>  Such as?  I must have missed that section in MC++ design. And anyway, how
>  would these issues apply here?

I detect some frustration, I mean you no disrespect, I hold your work and
comments in very high esteem.

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.

The problem with parameter inheritance, as least in this case, is that it
surprises programmers by causing an object to have an inconsistent
interface. Most programmers when confronted with code such as mytype::max()
expect that max will be available for all instances of mytype. On the other
hand, mytype::get_constraints().max() is generally understood to not always
be readily available in a parameterized type.

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

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

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