|
|
Boost : |
From: Joel de Guzman (joel_at_[hidden])
Date: 2007-11-20 03:31:35
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:
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk