From: Rob Stewart (stewart_at_[hidden])
Date: 2004-05-18 12:06:12
From: christopher diggins <cdiggins_at_[hidden]>
> 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
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
> > > 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_at_[hidden] Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk