Boost logo

Boost :

From: christopher diggins (cdiggins_at_[hidden])
Date: 2004-05-18 09:14:48


----- Original Message -----
From: "Rob Stewart" <stewart_at_[hidden]>
To: <boost_at_[hidden]>
Cc: <boost_at_[hidden]>
Sent: Tuesday, May 18, 2004 9:42 AM
Subject: Re: [boost] Ranged type mini-library submission

[snip]
> > I just changed the code by removing the public constraints typedef and
> > adding a static function get_constraints() so that it can be invoked
using
> > instances of an object as well.
> >
> > The problem with parameter inheritance, as least in this case, is that
it
> > surprises programmers by causing an object to have an inconsistent
> > interface. Most programmers when confronted with code such as
mytype::max()
> > expect that max will be available for all instances of mytype. On the
other
> > hand, mytype::get_constraints().max() is generally understood to not
always
> > be readily available in a parameterized type.
>
> 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'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 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.

Christopher Diggins
http://www.cdiggins.com
http://www.heron-language.com


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk