----- Original Message ----- From: "Jeff Garland" <jeff@crystalclearsoftware.com> To: <boost@lists.boost.org> Sent: Tuesday, May 18, 2004 9:24 AM Subject: Re: [boost] Ranged type mini-library submission
On Tue, 18 May 2004 00:17:40 -0400, christopher diggins wrote
I detect some frustration, I mean you no disrespect, I hold your work and comments in very high esteem.
No frustration, sorry it transmitted that way. Your statement was very broad, and implied that there are 'many problems' inheriting a template parameter.
I should not have made such a sweeping statement.
And yet I see it done sucessfully all the time in modern C++.
Since I'm basically unaware of 'problems' with this approach your statement hit me much like the ever recurring programming guildeline: "Don't use multiple inheritance because it might create problems". Complete bunk
It definitely is a powerful technique that I have used often. I am very hesitant about using it in libraries destined for public consumption when there exist alternatives which are more intuitive for naive programmers. that
needs to be corrected...
I understand.
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.
Well, ok, but I still don't like it.
The problem with parameter inheritance, as least in this case, is that it surprises programmers by causing an object to have an inconsistent interface.
This is really a matter of documentation. If I get used to calling mytype1::get_constraints().max() to find the max then I'm going to use my handy code editor to propagate
code around. As soon as I hit mytype2 that doesn't have constraints with a max function I'll be just as stumped as if mytype2::max didn't compile. Then I start looking at the docs and code to figure out what went wrong. But
I respect that, but my concern in this instance is whether Joe Average programmer will like it and understand it quickly. this then
I shouldn't expect a type with a name like 'divisible_by_four' to necessarily have a min/max interface.
I don't doubt that someone of your level of expertise would figure things out quickly, but my concern is with the lowest common denominator of experience. We are writing a library for the public, not for ourselves.
Most programmers when confronted with code such as mytype::max() expect that max will be available for all instances of mytype.
I assume here mytype refers to the constrained_value template? Because for a given user type generated from this template mytype::max will be available for all instances.
On the other hand, mytype::get_constraints().max() is generally understood to not always be readily available in a parameterized type.
Really? Let's say I've never seen the documentation for constrained_value and I'm just reading some code I didn't write. For me, I have to think for an extra nano-second ( little joke :) about the meaning of this code:
mytype::get_constraints().max()
I'm thinking let's see, a static function that returns an object with a max function. As opposed to just -- yeah, get the max.
mytype::max()
I don't see how the advantage of the shorthand justifies the case for parameter inheritance here.
I'll turn it around the other way -- I don't see how the 'longhand' makes
I stand corrected, I should have said all parameterizations. the
interface any clearer. The interface still needs a description the user can understand. In any highly flexible template design this is always more difficult.
An interface, as I am using the term here, is the set of public functions and public fields. An inteface for a parameterized type is generally understood to have functions or fields whose type is variant on a parameter. It is not generally understood or assumed that functions may or may not exist in a parameterized type.
One last point. By inheriting from the policy, we can both have our way. You can specilize your constraint policy to have a public method 'get_contraints' that returns an object and I can have my min/max. Now that's power ;-)
Your technique is most definitely more powerful but I am still concerned for naive users. Christopher Diggins http://www.cdiggins.com http://www.heron-language.com