Eric Niebler-4 wrote
Speaking strictly for myself here: the reason I haven't pushed to get my recent open source contributions into Boost is not because I consider my code of higher quality. If anything it's quite the opposite. Getting a library into Boost is so daunting and time-consuming that -- at least for the work I'm doing these days -- I just don't have the time.
My view is that if developing for Boost is taking extra time, you're doing it wrong.
I don't have the time to produce Boost-quality documentation.
If producing Boost quality documentation is taking extra time, you're doing it wrong. I'm not being facetious here. I think that one can't really verify that his library is correctly conceived and design until he tries to document it. In our world that means as clearly specified set of type requirements along with any other pre-conditions. The problem is that if you leave this until you're done, you discover that you've wasted a huge amount of time developing something that you don't really use - or could have been simpler.
and to exhaustively test everything.
If you're not writing the test as soon as you write a component how do you debug it? - or if your code doesn't need debugging (because its Eric Niebler I'm addressing here) How is anyone else sure it doesn't need debugging? You can't really progress without a test. So my suggestion is: a) start coding b) discover that something like "another variant type" is needed c) code "another variant type" d) code a test ofr "another variant type" e) debug at least part of it f) make the documentation for it - refine the type requirements g) go back and clean up the code and rerun the tests h) by this time you should have boost build or make scripts in order to test the damn thing. i) submit it to the boost incubator and see if anyone else can find complaints with "another variant type". This get's to free testers, comments, corrections and critiques. So far - you haven't done anything you won't have to do pretty soon anyway - an now you've got some free outsourcing j) pick he next piece and loop back to b) The only thing missing is the Boost Review process. It's hugely time consuming. It's useful - but not strictly necessary. What IS necessary to get your library considered for the standard is a concrete implementation with real world experience. All of the above steps are un-avoidable. So just submit it to the incubator and move on. If Boost want's to review it - great. If not - you'll still get most of the benefits. If you look at the library Safe Numerics in the incubator it has ONE review. For whatever reason, the author of that review put in some real effort. On the basis of his review I made a lot of small changes which will make a huge improvement in the safe numerics library. I don't really need Boost, I need the help and infrastructure that Boost members provide. They are not quite the same thing. I've skipped over one critical piece here. That is picking the right tools. Picking the wrong tools can consume a huge amount of time which doesn't contribute to the project. I spent a lot of time evaluating options for development tools and made my recommendations in the "Simple Tools" section of the incubator. The set I use and recommend aren't for everyone - but they do work well for me. Documentation in particular boils down to following a template for requirements and pre-conditions. Naturally Tutorial and Introduction can be added later. [note - off topic detour]
Concepts are coming.
dream on. The current versions looks to be captured in the "concepts lite" paper which is quite ill-conceived in my view. I have a huge problem with what I presume to be the canonical example they've chose "sortable". I talked about that at CPPCon. But besides that, we've had a simpler and "good enough" implementation of type requirements checking in the Boost Concept Checking library for over ten years - and hardly anyone uses it. A more elaborate version of something that isn't used is going to be used even less - not likely a success in my book. But then we never take any kind of poll about which features/libraries are actually used by C++ programmers. So we don't really have any idea what's really successful. This is perhaps a good thing. [end detour]
I needed to get on the Concepts train, and it was going to pull out of the station with or without me.
LOL - no way - it's guys like who are actually driving the train!
It would take half a year to make range-v3 Boost-worthy. By that time, I'd have missed my chance to get ranges baked in from day 1.
at the risk of repeating myself, you won't save any time by trying to shortcut the process.
Maybe that speaks to Boost's review process,
Factor the Boost review process out of the discussion. Make a boost quality library and let the Review process take care of itself. The main motivation for getting a library reviewed and accepted by boost is to get a certification of one's competence and accomplishment. You don't need any more of this from Boost. It wouldn't hurt, but you don't need it like the rest of us.
but it doesn't speak to the quality of Boost's code, which I consider very high.
It's variable. Considering the whole library - not just the code - In many case it needs to be higher - a lot higher.
I realize that doing an end-run around Boost to get ranges in the standard is deflating for everybody who has worked to make Boost what it is. That includes me.
I understand why people would look at it this way. And I think they're drawing on the wrong lesson. By skipping the Boost Review process, you're making a rational decision under the circumstances. It's a sign that boost has to evolve to stay current and relevant. How it has to evolve is something under active discussion. To me it's not deflating - it's inspiring!
FWIW, if someone were to volunteer to polish the docs and tests and run it through a review, I'd be overjoyed to see range-v3 in Boost. Ditto for Meta.
well finish them off and submit them to the incubator. Meta in particular would be interesting for a few reasons a) looks like you have it mostly done b) it's small interesting component of current interest - C++11+ and MPL replacement discussion c) it would let you demonstrate/test and lend credibility to the incubator d) it's the most likely way you might get someone to take over this part of the project - see free outsourcing above. e) Under "suggestions for libraries" there are two suggestions. Seems that Meta would fit in typlists - which I would prefer as library name as it dovetails better with A's book(s). I would like a separate smaller library for metafunctions - but I'm not sure if you've got that factored out or not. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/Another-variant-type-was-peer-review-queu... Sent from the Boost - Dev mailing list archive at Nabble.com.