On 1/14/2011 6:56 AM, Dave Abrahams wrote:
At Thu, 13 Jan 2011 21:49:10 -0500, Edward Diener wrote:
On 1/13/2011 8:42 PM, Dave Abrahams wrote:
At Thu, 13 Jan 2011 23:26:32 +0100, vicente.botet wrote:
You are right if the dependency is an implementation detail, not if the dependency appears on the interface.
Meh. You can always alias the dependency into the library under review for the purposes of the interface. In other words, instead of using boost::bar::x in the interface of boost::foo::f, use boost::foo::bar::x.
I think the idea is that...
I understand your point, Edward. I just think there are tractable (if slightly ugly) solutions available.
if library X depends on library Y, and library X gets reviewed before library Y, and library X gets accepted then:
1) Library X has to wait for library Y to be reviewed and Library Y has to then get accepted into Boost.
or
2) Library X has to duplicate the functionality of whatever it uses in Library Y.
I would rather say, "import" than "duplicate."
I do not understand the distinction you are making.
This does create some problems especially if library X heavily depends on Library Y and Library Y is not accepted into Boost.
Just do it the way Spirit/Fusion did it. When X is reviewed, make the parts of Y you need look like a sub-part of X. When Y comes up for review on its own, you adjust, implementing some backward-compatibility glue as needed.
I agree with that completely, and that's the way I design also. Still, in the scenario above, if library Y is not accepted there is work to be done in library X to implement under the hood whatever functionality from library Y it needed. But that's still not enough of a reason for library X to have to wait until library Y gets reviewed for it to get reviewed, and I think that was the point of your response.