From: christopher diggins <cdiggins@videotron.ca>
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.
Pardon me for assuming that design discussions take place before implementing code. You have posted various snippets and were discussing various things; I was working from that context.
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.
Possibly, but you posted rapid fire changes before design discussions subsided on various points, so I didn't feel the need to repeatedly download and view the code.
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.
Fine. You can justify your belligerence all you like. I thought I made some cogent arguments, despite the possibility of being slightly off course. A simple course correction from you would have sufficed. Since you prefer to attack rather than engage me, I'll leave the discussion to you and Jeff. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;