[boost] Re: is_base_and_derived

From: David Abrahams (dave_at_[hidden])
Date: 2003-10-28 20:34:09

Brian McNamara <lorgon_at_[hidden]> writes:

> On Mon, Oct 27, 2003 at 07:41:45PM -1000, David Abrahams wrote:
>> David Abrahams <dave_at_[hidden]> writes:
>> > Brian McNamara <lorgon_at_[hidden]> writes:
>> >> IMO this isn't worth the amount of discussion it's receiving,
>> >> though.
>> >
>> > Probably.
>> >
>> >> Just give me a "proper" (in the sense of "subset" v "proper subset")
>> >> version of is_base_and_derived, as well as the current version, and
>> >> call them whatever you like, and I will make sure that my code using it
>> >> works.
>> >
>> > Do you really have a use for the "proper" version where the other one
>> > work just as well?  That's my problem: I've never seen the use case.
>>  ^--- "won't"
>
> I don't have any example use-cases of my own for the "proper" version.
> That is to say, the non-proper version is all _I_ actually need.
>
>> > Having the "proper" version just to illuminate the semantics of the
>> > other one seems perverse to me.
>
> I disagree.  I think earlier today in another thread I heard you say
> something along the lines of "a design that's hard to document well
> reflects poorly on that design".  It seems to me that having both
>
>    is_subtype                    // or whatever we
>    is_proper_subtype             // choose to name them
>
> is the better design according to this documentation criterion.  

Having another trait in the library doesn't help me, in any way, to
document is_subtype.

> If there is only one option in the library, somewhere down the line
> someone will ask the question of "which" of these two functions it
> actually computes.

That's why you document the semantics with an explicit note.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com