Rob Stewart <stewart@sig.com> 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.
(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.
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.
There's also the question of whether "candidate" is the right word. One could make a case for "proposed," "tentative," and other words.
Those are fine with me too.
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. -- Dave Abrahams Boost Consulting www.boost-consulting.com