On 2015-08-29 01:07, Niall Douglas wrote:
On 28 Aug 2015 at 8:29, Roland Bock wrote:
I am unaware of any case where I imported a namespace except into a local context. Copied from the introduction page:
using namespace BOOST_AFIO_V2_NAMESPACE; That isn't a global using namespace. It could be a local using namespace, and in its original source file it is indeed a local using namespace.
And global or not is irrelevant: it makes example code hard to read if you are not familiar with the library.
But fair enough it could be interpreted differently, so logged to https://github.com/BoostGSoC13/boost.afio/issues/102.
Why is there a writable flag (why isn't constness enough to prevent writing)? I have no idea what you're going on about here, but constness at the language level has nothing to do with whether you open an on-disk store for reading or writing. First of all, please reread your claim: "World's simplest named blob store in STL iostreams"
What you present is definitely not what you promise. By simplest it was meant the public interface API. Not the implementation.
I would argue with Scott Meyers: http://programmer.97things.oreilly.com/wiki/index.php/Make_Interfaces_Easy_t... and others. I explained why write should be const for example. I explained why the writable flag is even working against the conditions you list yourself in that example. It is not the simplest API either.
I thought that obvious, but logged anyway to https://github.com/BoostGSoC13/boost.afio/issues/103.
Also, git has branches. Why don't you work on the half-baked stuff in a feature branch?
#if 0 is code smell. These are entirely personal opinion based on suppositions and assumptions with zero technical relevance to the quality of a library, as was a lot of the stuff I snipped. Of course it is personal. But it also happens to be shared by others. And since the library is meant to be used by others, why not listen to them?
Anyway. Up to you.
I don't work in pristine code environments, I like to keep around bits of code in #if 0 blocks to remind me of things, or for the occasional use, or for any other reason. I personally would find such segments educational when reviewing a library rather than the unfounded claim of "code smell" which may be true in other code bases in your experience, but I can assure you is not the case in my code bases. Wow. Speaking of unfounded...
Instead of assuming code smells or other non-factually based suppositions, consider examining the coverage of the unit test suite and the rigorous testing regime run each and every commit and taking some hours to complete. I would do that, once I understand, what needs to be tested. And btw, I know you are fully aware, that the quality of tests does not depend on coverage or the amount of time spent on running them. So why bring that up all the time?
I am trying to tell you where I have trouble comprehending the docs and the code. Since comprehension is a personal thing, sure, OK, you can call all this personal preferences. But they are neither unfounded, nor non-factual, nor do they have zero technical relevance (except maybe for you, which would speak volumes).