On 3/9/2011 2:15 PM, Nat Linden wrote:
I saw the Join library on the review queue and am somewhat curious. But I find the terminology a bit off-putting: ports, chords, joints. I've read the Introduction, the discussion on Join concurrency and the comparison with Futures/Promises. I know this sounds awfully dumb, but I still don't understand the moving parts or how they relate to each other. The Introduction leaves the impression that I could only understand (would only be interested) if I were already a fan of JoCaml or C(omega), neither of which I'd ever heard of before.
The library author might reasonably assert that I should read all the available documentation if I want to understand the library. But that's backwards: I have not yet found any reason why I should want to understand this library.
When I encounter a new Boost library, my first question is always: how would I use this? What problems in my work would be addressed by this library? How could it make my life easier? The closest I've so far gotten with Join is a vague sense that I could use it to implement Futures, if I didn't already have such a thing.
Were I not already somewhat curious about ways to organize async code, I wouldn't have read even this much of the documentation.
What's the point of this rant?
- I'd like to request a bit more introductory material. If one of the References includes an excellent discussion of why I should be interested, please promote the link (a specific section link) to the Introduction. Otherwise, please add some new prose with specific examples. - I'm aware that this may be clearer to others than it is to me. If you understand the proposed Join library and feel its documentation is sufficient, now would be a good time to say so.
My assumption at the moment is that if the Join library were accepted as-is into Boost, few people would even attempt to understand it because, like me, they would have a tough time figuring out how it might apply to their problem space.
This is actually one of main problem/issues I have with a lot of the boost libraries. I know there's some awfully good stuff in there, but with several of the libraries, the documentation does a poor job of telling me what it's actually all for. It must be interesting. People must be using it. But, why the heck would I ever want it? I admit some of that is my problem. Or at least perhaps, I haven't come across any situations that would warrant one these libraries. The problem, though, is that if I did come across that situation, I wouldn't necessarily know that there is a boost library solves that problem. -- Bill --