Re: [boost] Boost.Test updates in trunk: need for (mini) review?

Subject: Re: [boost] Boost.Test updates in trunk: need for (mini) review?
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-10-26 09:33:55

On Fri, Oct 26, 2012 at 5:41 AM, Ian Emmons <iemmons_at_[hidden]> wrote:

>
> On Oct 19, 2012, at 11:03 PM, Gennadiy Rozenal wrote:
> > It's been a long while since I merged any changes into boost release and
> by
> > now there are whole bunch of new features there. Some are small, but some
> > others are big ones such that they can change the way people use the
> library.
> > I'd like to list them here (excluding bug fixes and removal of deprecated
> > interfaces) and ask what should we do with these. Specifically let me
> know
> > if you think these require some kind of (mini) review from community,
> but any
> > other comments are welcome as well.
>
> Excellent stuff!  Thanks for this work.  I have a couple of comments.
>

I haven't been following too closely the proposed Boost.Test changes, but I
have some comments on your comments... :)

> First, __please__ pay attention to documentation.  I know you have said
> that documentation isn't something you like/want to do, but a library
> without good documentation is useful only to the writer.  In other words,
> it is (in a general purpose case like this) simply a waste of time.
>

+1

> Second, I have below suggested some terminology changes.  (Not for
> BOOST_CHECKA -- you have plenty of input on that.)  Some believe that a
> name is only a name, but I disagree.  Choosing names carefully is, in my
> opinion, a powerful means of communication and documentation.
>

+1

> > II. New "data driven test case" subsystem
> >
> > <<snip>>
> >
> > d) join - dataset constructed by joining 2 datasets of the same type
> >
> > int a[] = {1,2,3};
> > int b[] = {7,8,9};
> > data::make(a) + data::make(b) - dataset with 6 integer values
>
> This should be called "concatenation", not "joining".  People with a
> database background will expect something called "join" to increase the
> arity of the result.
>

"Join" is actually the terminology used by Boost.Range [1], so I think it's
entirely appropriate here, even given the many uses of join (I mean, one
could also argue that people with a math background might expect [2], but I
don't think that precludes the use of "join" in this context).

That said, "concatenation" sounds about as good.

> e) zip - dataset constructed by zipping 2 datasets of the same size, but
> not
> >         necessarily the same type
> >
> > This dataset has an arity which is sum of argument dataset arities.
> >
> > int   a[] = {1,2,3};
> > char* b[] = {"qwe", "asd", "zxc"};
> >
> > data::make(a) ^ data::make(b)
> > dataset with 3 samples which are pairs of int and char*.
>
> Calling this "zipping" is odd (at least to me).  Makes it sound like a
> compression facility.  Perhaps "tupling" would be better.
>

Again, Boost.Iterator has adopted "zip" [3] to mean precisely this, so I
think it's entirely appropriate. I don't know how zip conveys compression
other than in reference to the zip compression format, and...really, to be
honest, I'm not sure why "zip" was chosen for *that* name in the first
place.

"Tupling" has ambiguity with feature f) below, which also produces a
dataset of tuples, but in a different way.

I also think the choice of operator here is not ideal.  How does the xor
> operator evoke any notion of this operation?  I would choose bitwise-or "|"
> because that is sometimes used as a flat-file column delimiter.  (Actually,
> my favorite choice would be the comma operator to go along with the
> "tupling" terminology, but who am I to defy Scott Meyers' More Effective
> C++, Item 7?)
>
> > f) grid - dataset constructed by "multiplying" 2 datasets of the same
> different
> >          sizes and types type
> >
> > This dataset has an arity which is sum of argument dataset arities.
> >
> > int   a[] = {1,2,3};
> > char* b[] = {"qwe", "asd"};
> > double c[] = {1.1, 2.2};
> >
> > data::make(a) * data::make(b) * data::make(c)
> > dataset with 12 samples which are tuples of int and char* and double.
>
> For people with a database background, "cross product" is the obvious name
> for this.  Calling it anything else is silly.

Uh, this is Cartesian product [4], not a cross product [5], as far as I'm
concerned. Cartesian product > grid > cross product.

- Jeff

[1]
http://www.boost.org/doc/libs/1_51_0/libs/range/doc/html/range/reference/utilities/join.html
[2] http://en.wikipedia.org/wiki/Join_%28mathematics%29
[3] http://www.boost.org/doc/libs/1_51_0/libs/iterator/doc/zip_iterator.html
[4] http://en.wikipedia.org/wiki/Cartesian_product
[5] http://en.wikipedia.org/wiki/Cross_product_%28disambiguation%29