
on Sat Dec 01 2007, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
Joel de Guzman wrote:
* Un-reviewed implementation details of libraries have been placed in boost/detail if they need to be used by other libraries and a subdirectory of boost/<libraryname>/ otherwise. Their documented public components are placed in boost/detail and namespace boost::detail.
I think the current situation is a little problematic.
If there in boos/detail, presumable its because they might be useful accross more than one library.
Not usually. Usually it's because they *have* been useful across more than one library. In general, nobody sticks stuff in boost/detail just because they think it might have a use elsewhere. Components migrate there.
However,
There is no place for documentation of these things.
Sure there is. Comments work.
So there is no guarenteed interface.
And of course no separate tests.
Not necessarily. I always write tests for my library's implementation detail components.
No guarentee that the interface won't change - after all its an implementation detail. So it can change without warning an break other libraries.
So, one has a lot of reservations about depending upon these modules. On the other hand, they have proved very useful so for the sake of expediency they're going to get used - leading to surprise breakages.
That's more of a theoretical problem than a real one. It has never been an issue in the past. Most people realize that once a component moves into boost/detail, other people may be depending on it, so they make an effort to coordinate if there are any breaking changes (which, to my knowledge, there have never been in a boost/detail component).
So I think those things that have been going to boost/detail should just go into boost / utility. Approval for this would be part of the review process for the library which needed them.
Implementation details get invented and shared as part of a library's evolution, so that would never work
I realise some might find this bothersome, but its much better the the current situation.
I don't see why. A little common sense is all it takes to make this work out, and it has worked very well so far. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com