Re: [boost] Ranged type mini-library submission

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
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