----- Original Message ----- From: "Rob Stewart" <stewart@sig.com>
From: christopher diggins <cdiggins@videotron.ca>
From: "Rob Stewart" <stewart@sig.com>
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 is natural to assume that a parameterizing type meets the requirements of the template upon which it is used. If those include supplying min() and max() functions, then there's no surprise if things break when the parameterizing type fails to meet its obligation.
Supplying min() and max() is not an implicit requirement on a constraints policy. If you had bothered to look at the code at http://www.cdiggins.com/constrained_value.hpp before jumping in this conversation and expressing your opinions, then you might have realized that.
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 get it. Among the constraints are the minimum and maximum values the type may assume, right? Why wouldn't min() and max() be part of that interface?
Again, if you looked at the code posted: http://www.cdiggins.com/cv_test.cpp you would have realized that a constraint policy can represent things as diverse as modulo'ed integers or integers divisble by a given number.
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.
The desire to "dumb down" the interface is good until it bumps into other goals. Balance is the key. The question is what is more obvious to end users. I contend, with Jeff, that c_v.max() is more obvious and sensible than c_v_type::get_constraints().max(). That c_v.max() imposes a requirements on the parameterizing type, and that the parameterizing type is used as a base class, is not critical in my mind. The important thing is to document the requirements on the parameterizing type and on the constrained_value class template itself.
You might have mentioned it in one of your posts, but I didn't see where the object returned by c_v_type::get_constraints() would get its minimum and maximum values. Of what type is that object? How was that type determined? (Note: I haven't looked at your code, just your posts.) The answers to those questions will be telling as to how much you've reduced what you perceive to be cognitive complexity among the design alternatives.
I don't feel particularly inclined to respond to your questions or concerns until you invest at least the minimum of effort required to take a look at the code and read the other posts related to this topic. Christopher Diggins http://www.cdiggins.com http://www.heron-language.com