Re: Review: Boost Test Library

From: williamkempf_at_[hidden]
Date: 2001-02-16 13:31:06

--- In boost_at_y..., Kevlin Henney <kevlin_at_c...> wrote:
> In message <96ji2m+ipd2_at_e...>, williamkempf_at_h... writes
> >The names are fine, but we still have the question of whether or 
not 
> >we should be using acronyms.  With Boost in the name it's nearly 
> >impossible for us to conflict with other library names, but the 
> >acronyms are much more likely to collide with other acronyms 
already 
> >in use.  Even if this doesn't pose possible legal problems (does 
it?) 
> >it does make it more likely that the acronym will just confuse 
> >readers/users of the libraries.  The only compelling reason to 
keep 
> >them, as David Abrahams points out, is that the titles of the 
> >libraries are quite long and cumbersome for use in documentation 
and 
> >conversation.
> 
> I was never aware that we had a problem as serious as you make out, 
and
> remain unconvinced that we have. I had only considered the 
abbreviations
> to be a short-hand convenience for the full name rather than a
> replacement. In that sense, we should use them in docs as we would 
any
> other abbreviation (AOA), so that when we use AOA it is quite clear 
from
> the context.

Well, it's others that "make out" that the problem is serious.  The 
problem with abreviations, TLAs in particular, is that they are very 
likely to clash.  This topic began because I used the TLA BTL to 
refer to a post about the Boost Thread Library and someone pointed 
out that the recently submitted Boost Test Library has the same TLA.

My only concerns about using TLAs are:

1)  Within Boost they may clash and this will lead to very great 
confusion.
2)  Outside of Boost they may also clash, which may lead to some 
confusion for a smaller audience and possibly may be a trademark 
infringement(?).

Personally, I don't care too much about this issue for the upcoming 
Boost Thread Library, other than if some decision is made that will 
effect the documentation I'd like to know sooner than later.  So 
how "big" the problem is doesn't matter much to me.

Bill Kempf