From: David Abrahams (dave_at_[hidden])
Date: 2007-12-01 09:04:11
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
> 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
> 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
> 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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk