----- Original Message ----- From: "Rob Stewart" <stewart@sig.com> To: <boost@lists.boost.org> Cc: <boost@lists.boost.org> Sent: Tuesday, May 18, 2004 9:42 AM Subject: Re: [boost] Ranged type mini-library submission [snip]
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 understand mytype::get_constraints().max() to not always be available. If I wanted that information, I'd write that expression (instead of mytype::max()) and then be surprised when it didn't work.
When working with any parameterized type, it is natural to expect the return value of some functions to be of a type equal to a parameter. It is not natural to expect that the existance of methods to be conditional on the parameter.
It's simple enough to require that the template parameter supply min() and max() so that derivation yields those functions in mytype's interface. Then, it's a moot point whether min() and max() are part of a static or non-static interface for mytype.
The constrained_value type allows constraints which have nothing to do with min() and max() so requiring it in the parameter seems arbitrary.
I don't see how the advantage of the shorthand justifies the case for parameter inheritance here.
I don't see that you've solved any problem with your approach.
I am simply tryign to use parameterized types in a more manner that is more widely understood and fits the natural assumptions of programmers. Christopher Diggins http://www.cdiggins.com http://www.heron-language.com