Re: [boost] Re: is_base_and_derived

From: Brian McNamara (lorgon_at_[hidden])
Date: 2003-10-28 02:41:26

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.  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.  (I myself had been working under the false
assumption that the current is_base_and_derived was computing the
non-proper version of the subtype function.  I had been wrong all this
time, until being enlightened by this thread.  I believe if the library
had had two versions, which appeared next to each other on the
documentation page, I would never have fallen into this
misunderstanding in the first place.)

-- 
-Brian McNamara (lorgon_at_[hidden])