Boost is getting bigger and bigger. This is a good thing. The Boost header directory and boost namespace is also getting bigger and bigger. This is starting to become a problem. I would like to see: a) new libraries not add headers to boost directory or namespace. - with the possible exception - of "convenience headers" which include all the other headers for a library. Personally I don't like these, but since one doesn't have to use them its not a huge deal. b) authors of existing libraries which are implemented in boost directory/namespace would be encouraged to migrate them to a lower level. c) a couple of "catch all" namespaces/headers would be required such as "utility" for small libraries. I'm somewhat confused about "detail". If it's an implemenation detail of a particular library it should be in that library. If its a useful function which is shared by several libraries, it should be in something like: "unreviewed". And of course these should have thier test and documenations in the corresponding "lib" subdirectory. As boost get's bigger and bigger, it gets harder and harder to install just a part of it. But installing just a part of it is what users need to become confident about it. I realize that we've been circling around this topic for a while, I just want to keep it alive. Robert Ramey
Hi Robert, ----- Original Message ----- From: "Robert Ramey" <ramey@rrsd.com> To: <boost@lists.boost.org> Sent: Friday, October 08, 2010 8:46 PM Subject: [boost] Boost Evolution
Boost is getting bigger and bigger. This is a good thing.
The Boost header directory and boost namespace is also getting bigger and bigger. This is starting to become a problem. I would like to see:
a) new libraries not add headers to boost directory or namespace. - with the possible exception - of "convenience headers" which include all the other headers for a library.
+1
b) authors of existing libraries which are implemented in boost directory/namespace would be encouraged to migrate them to a lower level.
I agree with the directory, but not with the namespace. In particular I will see in the boost namespace every libary that is close to the standard, as for example Boost.Ratio.
c) a couple of "catch all" namespaces/headers would be required such as "utility" for small libraries.
I don't like "catch all" in general, but I recognize that utility is a good place to catch all small libraries. Anyway, I'm surethat there are some small libraries in Boost that are not in utility.
I'm somewhat confused about "detail". If it's an implemenation detail of a particular library it should be in that library.
+1, and I this that the name space should be prefixed by the name of the library as ratio::ratio_detail.
If its a useful function which is shared by several libraries, it should be in something like: "unreviewed". And of course these should have thier test and documenations in the corresponding "lib" subdirectory.
I disagree here. If is is useful to others it should be proposed for review if it can not be integrated in an existing library. Otherwise it is up to the author that is using the detail part to maintain it, at least respect to the user of her/his library.
As boost get's bigger and bigger, it gets harder and harder to install just a part of it. But installing just a part of it is what users need to become confident about it.
Why do we need to install part of Boost. Boost is a whole.
I realize that we've been circling around this topic for a while, I just want to keep it alive.
Best, Vicente
vicente.botet wrote:
From: "Robert Ramey" <ramey@rrsd.com>
I'm somewhat confused about "detail". If it's an implemenation detail of a particular library it should be in that library.
+1, and I this that the name space should be prefixed by the name of the library as ratio::ratio_detail.
Why not boost::ratio::detail? Why part namespace, part prefix? When I raised the issue with Boost.Ratio, the problem was you used boost::detail and I was concerned with cluttering that widely used namespace. If you had a boost::ratio namespace, then boost::ratio::detail would work. However, because your class template is boost::ratio<>, you can't have a boost::ratio namespace. You could have one named boost::ratios, so boost::ratios::detail would work. Is that a reasonable pattern to require for future/refactored libraries? _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
----- Original Message ----- From: "Stewart, Robert" <Robert.Stewart@sig.com> To: <boost@lists.boost.org> Sent: Friday, October 08, 2010 9:49 PM Subject: Re: [boost] Boost Evolution
vicente.botet wrote:
From: "Robert Ramey" <ramey@rrsd.com>
I'm somewhat confused about "detail". If it's an implemenation detail of a particular library it should be in that library.
+1, and I this that the name space should be prefixed by the name of the library as ratio::ratio_detail.
Why not boost::ratio::detail? Why part namespace, part prefix?
When I raised the issue with Boost.Ratio, the problem was you used boost::detail and I was concerned with cluttering that widely used namespace. If you had a boost::ratio namespace, then boost::ratio::detail would work. However, because your class template is boost::ratio<>, you can't have a boost::ratio namespace. You could have one named boost::ratios, so boost::ratios::detail would work.
Is that a reasonable pattern to require for future/refactored libraries?
There could be a conflict with other detail namespaces if the user adds using namespace boost; using namespace boost::ratios; It seems more unlikely that other libraries use ratios_detail as namespace, isn't it? I've seen that a lot of libraries uses detail namespace and others lib_detail. I think that I will move all my uses of detail to lib_detail. Best, Vicente
vicente.botet wrote:
From: "Stewart, Robert" <Robert.Stewart@sig.com>
vicente.botet wrote:
From: "Robert Ramey" <ramey@rrsd.com>
I'm somewhat confused about "detail". If it's an implemenation detail of a particular library it should be in that library.
+1, and I this that the name space should be prefixed by the name of the library as ratio::ratio_detail.
Why not boost::ratio::detail? Why part namespace, part prefix?
When I raised the issue with Boost.Ratio, the problem was you used boost::detail and I was concerned with cluttering that widely used namespace. If you had a boost::ratio namespace, then boost::ratio::detail would work. However, because your class template is boost::ratio<>, you can't have a boost::ratio namespace. You could have one named boost::ratios, so boost::ratios::detail would work.
Is that a reasonable pattern to require for future/refactored libraries?
There could be a conflict with other detail namespaces if the user adds
using namespace boost; using namespace boost::ratios;
Of course there could. This can go on ad infinitum, but we do see value in namespaces. In that particular case, one can still write boost::detail or boost::ratios::details or ratios::details to disambiguate. If there are names in common and one tries to use such a name, then there will be an ambiguity which must be resolved. The difference is that the names will be in different namespaces and can be disambiguated, whereas two libraries that put the same name into boost::detail simply cannot coexist.
It seems more unlikely that other libraries use ratios_detail as namespace, isn't it?
That is just as unlikely as two libraries using boost::ratios::detail.
I've seen that a lot of libraries uses detail namespace and others lib_detail. I think that I will move all my uses of detail to lib_detail.
If all new libraries use lib_detail rather than detail, the problem just shifts, unless you mean <lib>_detail, where "<lib>" is replaced by the library name. Still, as I've shown, that simply mixes paradigms making it a little more surprising, I should think. If we can establish that pattern as desirable, then new libraries can adopt it and it will be expected, of course. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On Oct 11, 2010, at 6:42 AM, "Stewart, Robert" <Robert.Stewart@sig.com> wrote:
If all new libraries use lib_detail rather than detail, the problem just shifts, unless you mean <lib>_detail, where "<lib>" is replaced by the library name. Still, as I've shown, that simply mixes paradigms making it a little more surprising, I should think. If we can establish that pattern as desirable, then new libraries can adopt it and it will be expected, of course.
Don't forget you can always use locally-defined namespace aliases, e.g. namespace brd = boost::ratios::detail defined within boost::ratios, to avoid such collisions. -- BoostPro Computing * http://boostpro.com [Sent from coveted but awkward mobile device]
On Oct 11, 2010, at 6:54 AM, Dave Abrahams wrote:
On Oct 11, 2010, at 6:42 AM, "Stewart, Robert" <Robert.Stewart@sig.com> wrote:
If all new libraries use lib_detail rather than detail, the problem just shifts, unless you mean <lib>_detail, where "<lib>" is replaced by the library name. Still, as I've shown, that simply mixes paradigms making it a little more surprising, I should think. If we can establish that pattern as desirable, then new libraries can adopt it and it will be expected, of course.
Don't forget you can always use locally-defined namespace aliases, e.g. namespace brd = boost::ratios::detail defined within boost::ratios, to avoid such collisions.
I haven't been following this discussion closely but is there any way to use namespaces for version control along the lines of what Stroupstrup mentioned in D&E? It's been quite a while since I looked at it but perhaps with suitable modification it could help address some of these concerns. -- Noel
At Mon, 11 Oct 2010 10:20:33 -0600, Belcourt, Kenneth wrote:
On Oct 11, 2010, at 6:54 AM, Dave Abrahams wrote:
On Oct 11, 2010, at 6:42 AM, "Stewart, Robert" <Robert.Stewart@sig.com> wrote:
If all new libraries use lib_detail rather than detail, the problem just shifts, unless you mean <lib>_detail, where "<lib>" is replaced by the library name. Still, as I've shown, that simply mixes paradigms making it a little more surprising, I should think. If we can establish that pattern as desirable, then new libraries can adopt it and it will be expected, of course.
Don't forget you can always use locally-defined namespace aliases, e.g. namespace brd = boost::ratios::detail defined within boost::ratios, to avoid such collisions.
I haven't been following this discussion closely but is there any way to use namespaces for version control along the lines of what Stroupstrup mentioned in D&E? It's been quite a while since I looked at it but perhaps with suitable modification it could help address some of these concerns.
I think we have some new feature in C++0x that makes it “more possible.” Oh, yeah: http://www2.research.att.com/~bs/C++0xFAQ.html#inline-namespace I take this as an indicator that what we have in C++03 isn't quite optimal, but maybe we can do something adequate. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Oct 11, 2010, at 11:02 AM, David Abrahams wrote:
At Mon, 11 Oct 2010 10:20:33 -0600, Belcourt, Kenneth wrote:
On Oct 11, 2010, at 6:54 AM, Dave Abrahams wrote:
On Oct 11, 2010, at 6:42 AM, "Stewart, Robert" <Robert.Stewart@sig.com> wrote:
If all new libraries use lib_detail rather than detail, the problem just shifts, unless you mean <lib>_detail, where "<lib>" is replaced by the library name. Still, as I've shown, that simply mixes paradigms making it a little more surprising, I should think. If we can establish that pattern as desirable, then new libraries can adopt it and it will be expected, of course.
Don't forget you can always use locally-defined namespace aliases, e.g. namespace brd = boost::ratios::detail defined within boost::ratios, to avoid such collisions.
I haven't been following this discussion closely but is there any way to use namespaces for version control along the lines of what Stroupstrup mentioned in D&E? It's been quite a while since I looked at it but perhaps with suitable modification it could help address some of these concerns.
I think we have some new feature in C++0x that makes it “more possible.” Oh, yeah: http://www2.research.att.com/~bs/C++0xFAQ.html#inline-namespace
I take this as an indicator that what we have in C++03 isn't quite optimal, but maybe we can do something adequate.
Ah, nice. Thanks for the link. -- Noel
vicente.botet wrote:
I'm somewhat confused about "detail". If it's an implemenation detail of a particular library it should be in that library.
+1, and I this that the name space should be prefixed by the name of the library as ratio::ratio_detail.
Why? boost::ratio::detail is distinct from boost::polygon::detail and unambiguously so. Namespace is the preferred style option to naming convention with prefixes to prevent ambiguity/collisions, I see no reason to use both. Regards, Luke
----- Original Message ----- From: "Simonson, Lucanus J" <lucanus.j.simonson@intel.com> To: <boost@lists.boost.org> Sent: Friday, October 08, 2010 10:25 PM Subject: Re: [boost] Boost Evolution
vicente.botet wrote:
I'm somewhat confused about "detail". If it's an implemenation detail of a particular library it should be in that library.
+1, and I this that the name space should be prefixed by the name of the library as ratio::ratio_detail.
Why? boost::ratio::detail is distinct from boost::polygon::detail and unambiguously so. Namespace is the preferred style option to naming convention with prefixes to prevent ambiguity/collisions, I see no reason to use both.
To ensure unabiguous behavior, I will need to use on the Boost.Ratio code ratio::detail, which is quite close to ratio_detail. The advantage of the last is that it avoid the direct use of detail which could be ambiguous. Vicente
vicente.botet wrote:
Hi Robert,
If its a useful function which is shared by several libraries, it should be in something like: "unreviewed". And of course these should have thier test and documenations in the corresponding "lib" subdirectory.
I disagree here. If is is useful to others it should be proposed for review if it can not be integrated in an existing library. Otherwise it is up to the author that is using the detail part to maintain it, at least respect to the user of her/his library.
In detail, one finds some things like: utf8, lightweight test, among other things. In fact I use both of test so I know they are used by multiple libraries. So this raises the question as to where they should go. They are in fact unreviewed and they are not an implementation detail of only one library. They're not going away. The main thing that bothers me is that there is no place for their documentation, tests, etc. 'utility" would be fine except for the fact that they are unreviewed - so that's why I picked "unreviewed.
Why do we need to install part of Boost.
As boost get's bigger and bigger, the probablilty of failure to install and pass tests gets larger and larger. So if someone wants to use just one library to start he has to do the whole thing. If he could do it one are a few libraries at at time it would be much easier to ease into boost. Also, there are many platforms (embedded and ?) which could not run all of boost. If one has one of those, he has to install all the libraries and then read and discard all the failures - a time consuming and confidence shaking excercise. I would expect the in the future one would be needing one component - say shared_ptr, and just install that. just installing that (and it's dependents) would take probably only a minute - maybe two if one ran the tests and the user would be right where he needs to be. Also, one would not have any accidental dependcies on a bunch of other code. There a lot's of reasons to make granularity finer.
Boost is a whole
It is now. That's what I believe will have to change, My view is that it's becoming an obstacle to growth and usablility because installation, testing, maintenance and deployment are not scalable. Robert Ramey
At Fri, 8 Oct 2010 10:46:33 -0800, Robert Ramey wrote:
Boost is getting bigger and bigger. This is a good thing.
The Boost header directory and boost namespace is also getting bigger and bigger. This is starting to become a problem.
Specifically, how? I don't like it either, but I'd like to know what the real-world effects are.
I would like to see:
a) new libraries not add headers to boost directory or namespace. - with the possible exception - of "convenience headers" which include all the other headers for a library. Personally I don't like these, but since one doesn't have to use them its not a huge deal.
b) authors of existing libraries which are implemented in boost directory/namespace would be encouraged to migrate them to a lower level.
c) a couple of "catch all" namespaces/headers would be required such as "utility" for small libraries. I'm somewhat confused about "detail". If it's an implemenation detail of a particular library it should be in that library. If its a useful function which is shared by several libraries, it should be in something like: "unreviewed".
But in general it's not unreviewed code. It was usually part of a library that passed review, and then the code was factored out. So it doesn't have the same standing as a Boost library, and it may not have any user-level documentation, because... it's an implementation detail of various Boost libraries.
And of course these should have thier test and documenations in the corresponding "lib" subdirectory.
As boost get's bigger and bigger, it gets harder and harder to install just a part of it. But installing just a part of it is what users need to become confident about it.
I realize that we've been circling around this topic for a while, I just want to keep it alive.
Don't worry, Ryppl isn't dead either; it's just been quiet for a while ;-) -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Fri, Oct 8, 2010 at 9:29 PM, David Abrahams <dave@boostpro.com> wrote:
At Fri, 8 Oct 2010 10:46:33 -0800, Robert Ramey wrote:
Boost is getting bigger and bigger. This is a good thing.
The Boost header directory and boost namespace is also getting bigger and bigger. This is starting to become a problem.
Specifically, how? I don't like it either, but I'd like to know what the real-world effects are.
Try including boost.lambda and boost.bind to your project. Consider boost.bind, boost.lambda, boost.spirit and boost.phoenix (i am sure there are others too), they all define some placeholder named _1, _2 ... now imagine they all lived in the same namespace!
On 08/10/2010 21:15, Thomas Heller wrote:
Try including boost.lambda and boost.bind to your project. Consider boost.bind, boost.lambda, boost.spirit and boost.phoenix (i am sure there are others too), they all define some placeholder named _1, _2 ... now imagine they all lived in the same namespace!
At least it would mean we would get rid of the inferior versions.
David Abrahams wrote:
At Fri, 8 Oct 2010 10:46:33 -0800, Robert Ramey wrote:
Boost is getting bigger and bigger. This is a good thing.
The Boost header directory and boost namespace is also getting bigger and bigger. This is starting to become a problem.
Specifically, how? I don't like it either, but I'd like to know what the real-world effects are.
a) >> As boost get's bigger and bigger, it gets harder and harder to
install just a part of it. But installing just a part of it is what users need to become confident about it.
b) suppose I start with my "small" embedded system. Now I need shared_ptr and so I install boost. Now when something unexpected happens, I've now got to consider that that something is among thousands of lines of code that I for all practical purpposes I can't inspect. The giant size of boost means that I can accidently inject dependencies without being aware of them. Even if it never happens, I now have to consider this possibility everytime I have a problem. c) It's a real obstacle to convincing programmers to install and experiment with boost. These are already problems right now. They'll only get worse.
c) a couple of "catch all" namespaces/headers would be required such as "utility" for small libraries. I'm somewhat confused about "detail". If it's an implemenation detail of a particular library it should be in that library. If its a useful function which is shared by several libraries, it should be in something like: "unreviewed".
But in general it's not unreviewed code. It was usually part of a library that passed review, and then the code was factored out. So it doesn't have the same standing as a Boost library, and it may not have any user-level documentation, because... it's an implementation detail of various Boost libraries.
Hmmmm - if its reviewed and placed in a "global" namespace like boost::detail why not just include it in boost::utility then? if its used for just one library, then why not make it a part of that one library rather than putting it in a global namespace?
And of course these should have thier test and documenations in the corresponding "lib" subdirectory.
Which we don't currently have this for "detail" components.
I realize that we've been circling around this topic for a while, I just want to keep it alive.
Don't worry, Ryppl isn't dead either; it's just been quiet for a while ;-)
I see this evolution as something necessary on it's own. Rypple may or maynot occur, but I think boost should evolve in this direction regardless. For now, I'm proposing these changes only for new libraries. Robert Ramey
At Fri, 8 Oct 2010 13:20:25 -0800, Robert Ramey wrote:
But in general it's not unreviewed code. It was usually part of a library that passed review, and then the code was factored out. So it doesn't have the same standing as a Boost library, and it may not have any user-level documentation, because... it's an implementation detail of various Boost libraries.
Hmmmm - if its reviewed and placed in a "global" namespace like boost::detail why not just include it in boost::utility then?
sure, if you'll agree to document and maintain it at a level suitable for users, be my guest :-) Also, theoretically, putting new components in boost::utility requires some kind of additional review process. I think we need a separate designation for the sorts of things that end up in boost::detail.
if its used for just one library, then why not make it a part of that one library rather than putting it in a global namespace?
That's exactly what one does. The only reason most of us ever put something in boost::detail is that it's needed by multiple libraries.
Don't worry, Ryppl isn't dead either; it's just been quiet for a while ;-)
I see this evolution as something necessary on it's own. Rypple may or maynot occur, but I think boost should evolve in this direction regardless. For now, I'm proposing these changes only for new libraries.
Well, we could do Boost modularization separately from ryppl. Eric's been maintaining a modularized mirror of boost at http://github.com/boost-lib -- Dave Abrahams BoostPro Computing http://www.boostpro.com
participants (9)
-
Belcourt, Kenneth -
Dave Abrahams -
David Abrahams
-
Mathias Gaunard -
Robert Ramey -
Simonson, Lucanus J -
Stewart, Robert -
Thomas Heller -
vicente.botet