Boost logo

Boost :

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-03-23 16:45:19


From: David Abrahams <dave_at_[hidden]>
> Rob Stewart <stewart_at_[hidden]> writes:
>
> >> Well, my intention is to make things clear, but not to make people
> >> write/speak unnaturally. I don't want to be heavyhanded about this.
> >> I would like to see one other person agree with you that it's a good
> >> idea before including it in the document.
> >
> > I've heard from no one for or against my ideas, or yours for that
> > matter. Does anyone have an opinion on how this should be
> > codified? What do you think should be the official naming
> > convention?
>
> I don't have an opinion; I don't think we need an official naming
> convention. I just want people to distinguish accepted from proposed
> libraries in their speaking and writing. No need to make a big
> production of it.
>
> > So, the question remains: Is "Boost Candidate.Name" instead of
> > "Boost.Name" a good idea in message traffic prior to acceptance?
>
> I should think my opinion would be obvious by now: "Boost
> Candidate.Name" is better than "Boost.Name" for that purpose. OTOH I
> don't care if someone wants to say "proposed Boost.Name" or whatever.

I didn't do a very good job in my message, but I started out by
using "your" to refer to you, and from that point forward, I was
referring to everyone in order to seek feedback. Yes, I already
knew your opinions on the matter. I'm sorry for the confusion.

> > (For that matter, Boost.Book and QuickBook could be modified to
> > generate such names automatically, with a switch that indicates
> > that a library has not yet been accepted.)
>
> Overhead. Complication. This is a simple thing; no need to make it
> into something big.

Yes, I can understand your thinking that this would be too much
if you think nothing formal need be done in the first place.

> > If you don't like that, do you think "candidate Boost.Name" is
> > good enough? My concern is that "candidate," being lower case,
> > will pale next to "Boost.Name" and so lose its value.
>
> It's not that imporant.

What about those that expressed the opinion that using
"Boost.Name" diluted the value of Boost acceptance? Is candidate
Boost.Name really good enough? Notice that "candidate" can be
separated from "Boost.Name" as I did it in the last sentence.
Doesn't that make "Boost.Name" stand out and suggest official
status? OTOTH, Boost Candidate.Name offers no room for such
confusion.

> > Is there any reason to have a different modifier for libraries in
> > the review queue as compared to those simply under development
> > with aspirations to be reviewed? For example, the former case
> > could readily use "candidate" or "proposed," whereas the latter
> > is not properly a Boost candidate, since it hasn't yet been
> > proposed for review, and so might better be described as
> > "potential."
> >
> > Dave has made the case for not requiring name changes in
> > documentation. If it can be done easily enough via Boost.Book
> > and QuickBook, I think it is reasonable to expect it in
> > documentation generated with those tools. However, since the
> > use of those tools is not required, then it would be simplest and
> > most consistent to simply state that documentation need not
> > alter Boost.Name.
> >
> > Let me know what you think should be our naming requirements.
> > Once we reach consensus, I'll create a diff for
> > more/discussion_policy.htm to capture them.
>
> The requirements should be "distinguish accepted boost libraries from
> things someone hopes will be in Boost, someday." Beyond that, I don't
> care.

If your laissez faire approach is acceptable to folks, then I
agree. If something a little more formal is desirable, then
something else is needed. I'd like to see some consensus from
folks on the list.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk