I agree with nearly all of Thilo's comments on this subject. On Oct 28, 2005, at 9:06 PM, Andre Merzky wrote:
Questions:
Q1) any comments to the Boston discussion? I hope I reflected that correctly... Q2) are there any drawbacks by introducing 4a or 4b, apart from the additional number of calls?
I think it is good. (go for it)
Q3) Are the advantages (simplicity for most usages, powerfull for bulk operations and others) good enough to introduce 4a or 4b?
We want a more concise way of describing async operations, so this is good.
Q4) You like 4a or 4b better?
I do not like 4b. The flags seem very klunky. I think the naming of the method call is a more effective means of communicating its function (it is certainly more readable than code that uses the flags). Readability is very important.
Q5) Any comments to 4a1, 4a2 or 4a3? (not part of the Strawman!)
I prefer 4a1 because it is more readable and the implementation would be quite straightforward. It is also a familiar paradigm for any MPI programmers and anyone who has played with various proprietary Async I/O implementations. (its a very familiar and conventional approach) I kind of like 4a2 as well from the standpoint of a C++ programmer (even with Andre's syntax corrections). However, the resulting bindings will not be very consistent with the approach we would take for Fortran or C bindings (eg. those would likely look more like 4a1). It is not really much more readable than 4a1. Therefore, I'm uncertain if it is worth fragmenting our approach to bindings in different languages when there is not a clear benefit in terms of readability or implementation complexity. I do a lot of C++ programming, but I find the 4a3 option a bit obscure both in terms of readability and any advantages it might confer in terms of implementation. It would certainly be easier to create multi-language bindings for a single code base if we stick with something more conventional like 4a1. Each approach is equally readable to me (less so for 4a3). I'm certainly open to any additional information on how the 4a2 and 4a3 approaches could simplify implementation. If the other approaches can offer some implementation benefits, then maybe I'd give them extra consideration, but otherwise, I would prefer a more conventional approach like 4a1. The only implementation I'm outright against is the 4b example. -john