From: Rob Stewart (stewart_at_[hidden])
Date: 2004-05-18 08:42:03
From: christopher diggins <cdiggins_at_[hidden]>
> From: "Jeff Garland" <jeff_at_[hidden]>
> > On Mon, 17 May 2004 11:53:49 -0400, christopher diggins wrote
> > > There are just so many problems that can arise from
> > > parameterized inheritance, I would like to avoid it if there is an
> > > acceptable alternative.
> > Such as? I must have missed that section in MC++ design. And anyway, how
> > would these issues apply here?
> I detect some frustration, I mean you no disrespect, I hold your work and
> comments in very high esteem.
I think you misunderstood. He was just trying to find out what
left the bad taste in your mouth.
> 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.
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.
> 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.
-- 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