[ This is more thoughts (and questions!) about the work on the object-model branch. If you don't care about the nuances of such things, you can stop reading now, and save your cycles for shipping 1.7 work. :) ]
I'm trying to determine the best way to return objects from the various wrapping classes found in Types.h [1]. At issue here is how to return NULL values back to callers. Recall from a previous discussion that these classes simply hold a handle to the underlying C structure, and then implement getter methods to enable the caller to pull information out of them. (We may change the implementation down the road, but the API seems reasonable.) Currently, we return this information by value, relying upon compiler optimizations to eliminate unneeded copies, etc. The problem with this approach is that many of our C structs are incomplete, that is, they contain only certain subsets of values, with other values represented as NULL pointers. This creates a problem when attempting to return these NULL values by value in the C++ bindings. The "obvious" solution is to return the problematic values by pointer, but that introduces difficulties of its own. I see the following options: 1) Return everything by value Pros: simpler memory management, less overhead (?) Cons: doesn't allow the return of NULL values, need to establish conventions to represent NULL objects (an isNull() method?) 2) Return everything by pointer Pros: can represent the NULL value, potentially less memory overhead Cons: more complex memory management (caller must delete returned value) 3) Some combination of (1) & (2) Pros: Can return guaranteed existing things by value, potentially NULL ones by pointer Cons: Making the distinction between optional and required takes more effort, a heterogeneous API is more work for callers I'm leaning toward (2), even though it requires a bit more management on the part of callers, I think it's the better approach to take. It's not as clean, but still allows the use of the NULL value, which callers can use in the normal fashion. I've not explored how this would impact swig's ability to generate bindings based on the C++ object model, though. Thoughts? -Hyrum [1] http://svn.apache.org/repos/asf/subversion/branches/object-model/subversion/bindings/c++/include/Types.h
