Robert Ramey wrote:
Joel de Guzman wrote:
Robert Ramey wrote:
You mention below that you based that action by following static_assert.hpp. You see now why it is wrong? There's a big difference -- static_assert was reviewed. Yours is not. To be considered a boost library, it must be reviewed independently outside of serialization.
So its not the placement itself that's wrong?
I think so, yes. static_warning can very well be a "core" library like static_assert IFF it has undergone a boost review and is accepted.
The error is is only that it reviewed as part of something else rather than independently?
Yes. That's the crucial misinterpretation of the process and the (unwritten) standard practice. The libraries I authored, for instance, has tremendous amount of support code that ideally could exist outside the framework as stand alone components. These parts have undergone the same review process as serialization components did. If I, or all libraries that has been accepted thus far, were to place them outside the sphere of their host into root, imagine the result.
So the correctness of the placement of such a module is defined in terms of the outcome of a formal review?
Correctness of a lot of things depend *not only* on the formal review. We can never have a perfect system.
Does that seem like a practical system to you?
Well, unless you have a better suggestion, the current review process works. It's up to us to uncover the glitches and propose remedies and workarounds or, if you will, better processes.
Suppose static_warning.hpp were reviewed and for some reason it was rejected and it were moved into the serialization library. Then we would have the situation where two very similar libraries would be in two entirely different places. Would this be logical from the standpoint of someone examining boost and trying to understand where stuff is?
No. And that is unfortunate.
Should review results be included as permanent part of every library?
Not sure about that. At least an immediately accessible record of all the reviews would be helpful, I think.
Note that these are rhetorical questions meant to illustrate my view that defining the "expected placement" or "standard whatever" which depends upon the result of a formal review (especially when examination of such a review) has some problems. What is better is a stated policy and a review acceptance process which enforces conformance to such a policy. Perhaps had such a policy existed at the time and the formal review process stated that comformance to such a policy was one of the things to be checked, this particular instance might be been addressed at an opportune time.
Agreed. Still, even after we settle this issue for now, there will still be things that we will not catch and even more things that will be uncovered in the future that we've missed yet may be detrimental to the health of boost in the future to come. There's no silver bullet. We can only try to do our best, as we always have. What's equally important is that we remain agile to future changes and accept that we do make mistakes, we do uncover unforeseen bugs. And it is part of the ongoing process to correct them when we find them.
I previously posted the following list. I'm not sure which ones are convenience headers and which are not. But somehow I don't think they've all been independently reviewed. given that there in the boost directory I don't know where to look for the documentation without out doing some sort of search. (Hmmm - now I'm curious what something like "none.hpp" does. ahhh - its parto of optional.hpp.)
[snip list] Once we settle this, we can run through the list and inform the author of the violation, if there is one. I notice though that most of the items in your list have been reviewed. Can you please trim your list to only those like static_warning? none.hpp is probably one of them, AFAIK.
Resistance to change something that is broken does not help. You do agree that free for all pollution of the root directory and namespace is not good, right?
I do - I was just trying to follow established patterns. But now you raise the real issue. Given the size that boost has grown to and the problems that this has engendered I don't think that there should be anything in the boost directory/namespace other than convenience headers. (personally I don't even like convenience headers but I'm think I'm in the minory on this point.)
In my mind, that would be ideal, yes. But I'm not sure it's practical as this would cause massive breaking for existing libraries.
lots of people did and there is.
I don't think it's chaos at this point. There's still chance to correct the trend. I'll reply to the rest of your post in a new thread later. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net