Robert Ramey wrote:
a) No new headers in boost/... Boost is too big for this Forward headers are ok. I also don't see a problem with reviewed libraries which have a small single header to be placed there. Ideally, the header would follow the pattern:
lib.hpp
where "lib" is the name of the reviewed library.
I see a big problem. Defining the directory placement in terms of a review means that developers can't really make the library until after its review. Its like sending every court case to the legislature. It means extra work for developers. It means that one doesn't really know where to look for something.
I don't quite understand what you mean here. Please elaborate.
b) small libraries can be placed in boost/utility and ancillary files such as tests, source code, documentation, etc be placed in the same spots they are as other libraries As long as they passed the review process.
Actually everything in boost should be subject to some sort of review process. And it is even though its sometimes sort of informal for smaller changes and additions.
No, that would be too slow and bureaucratic. Libraries can add their own modules and upgrade as needed without having to undergo another review. Individual libraries, can host such utilities or even sub-libraries until they are reviewed separately. Only then can they be promoted outside its host and into boost.
c) No concept of "core libraries" vs "non-core" libraries You'll have a hard time defending that. The concept of "core library" has been with us since time immemorial. Just search the lists. Why are you so against this?
For a couple of reasons:
a) it's subjective and arbitrary - (one more think to be decided by commitee)
It can be part of the review. If the author of a library intends it to be a "core" library, he can explicitly say so and be subject for the review.
b) it's unnecessary - (the concept doesn't add anything)
It does. The shared_ptr is a core library. I do not want to spell it out as boost::smart_ptr::shared_ptr. It's pretty much common to all libraries. Also, it gives us structure. Typically "core" libraries have the highest number of dependency in terms of structure. If you look at the dependency diagram of boost, the core libraries will be at the bottommost with lots of other modules pointing acyclically at it. It's a must to avoid having them depend on other libraries in other layers above the core. It's good that smart folks like Peter Dimov knows what they are doing by keeping the strict acyclic relationship. More emphasis and constraints must be given to these "core" libraries as they form the backbone of boost as a whole. I do not want to touch on that, however, to not digress from the subject.
c) it's confusiing - one looks for something in different places depending on whether one thinks its a "core library" or not.
Subjective.
d) once I do #include boost/none.hpp its not obvious anymore what other libraries my own code depends upon.
Is none.hpp a "core" library? Was it individually reviewed? If not, then it's probably in violation too.
e) it's not scalable. This is the big one. As boost gets bigger the number of "core libraries" (regardless of how its defined) will have to grow. This will make all the problems it generates that much worse.
It is scalable. Surely it will grow, but its size will be a fraction of the whole of boost. Not a lot of libraries can be considered core. Only a few.
f) To me its inevitable that boost will have to move more toward the spirit model of development. That is, larger libraries, and maybe all of them, being an asyncronous process which depends upon the latest release of other libraries. I know there is resistence to this, but I think that it is inevitable regardless. having stuff in boost/... make this process more painful than it already its.
Spirit itself has a "core" and such structuring makes a lot of sense in terms of organization. All libraries I authored have the concept of a "core". Ok, this may be besides the point, but I just want to emphasize that I am all for structuring and layering. Actually, I am for having more than the core. Right now, We have utility and core. That's a good start. But to give you an idea, Spirit has this organizational structure: http://tinyurl.com/ywr2fo Such a layering structure is very scalable. It is also very intuitive to just look at it, reason out, etc. in a high level, if you have such a layering structure in place.
g) I'm already having problems with namespace clashes. I used Multi_Index and it used aligned_storage. Some sort of namespace issue which seems in this case to be precipated by a compiler bug. So maybe its not the best example but it took a fair amount of time to track down. Its very confusing to have assert.hpp in boost/... as well as in some other libraries - and can lead to hard to find bugs.
These symptoms are not caused by having a "core". Irrelevant.
d) exception to a) one convenience header per library Ah, ok.
LOL - and I don't even like convenience headers myself.
e) documentation in boost/libs/utility/doc/... same as other libraries
again, as long as those are reviewed.
well everything is reviewed. The questions at hand would be
a) If a new library has a component which is of such a nature that it really stands apart from the library itself, is it OK that it be placed in a more central spot like boost/utility.
That question should be part of the review. The author should state her wish that the library be part of 'core" or "utility". Ultimately, the review manager decides.
b) Is it OK for review of such a component to be handled as part of the review for the whole library.
Perhaps not. That's a question best addressed by the review folks.
c) Does acceptance of a library imply acceptance of such a component or not.
No.
a) would be a question of policy. As these things will vary from case to case, b) and c) things should be added to the review manager's checklist.
f) library authors encourged to move components over time out of boost. This would include ALL the ones I posted before (except for those which are convenience headers). Tweak: encourged to move *unreviewed* components over time out of boost.
ReTweak: *ALL*
Why not ask for a review for all these in one shot. Dunno if that's possible though.
LOL - that's what I thought I was getting when I went through the TWO orginal reviews.
Yes. Given the considerations above. I see it's not a good idea. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net