From: christopher diggins (cdiggins_at_[hidden])
Date: 2004-05-18 10:40:31
----- Original Message -----
From: "Rob Stewart" <stewart_at_[hidden]>
> From: christopher diggins <cdiggins_at_[hidden]>
> > From: "Rob Stewart" <stewart_at_[hidden]>
> > > 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
> > 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
> > > 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
> > 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
> > > > 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
> > 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk