Fernando wrote:
Do you write "implies OO" as in "implies member functions"? If so consider that lots of people, specially here, consider that tempate free-functions are just one OO-style. That Meyer's article Joel pointed out explains why. Yes, I read the Meyer's article and other similar articles encouraging non-member, non-friend functions. I think it is safe to say that my data structures are fully encapsulated through a minimal and sufficient interface, the ConceptMap. In addition to that I add a minimal and sufficient interface between the library functions in the Concept class and the ConceptMap, allowing even the concept map to change without needing to change my library functions. I achieve all the goals Meyer's describes already. If I have achieved the goal already, why should I change the code?
Assuming you disagree, can you show us which goal(s) _need_ the approach >you choosed instead of the "functional" one? Ease of use. Since my design is flexible, robust and has good encapsulation already I have the luxury of allowing myself to provide the "good old fashioned" style of API that my users want. If I made my library completely different from what they used before that would hurt uptake and slow down its penetration rate.
Note: your library design in on the edge of not being "generic programming" but merely parametrized old school object-oriented programming. It has some genericity scent since at least you can adapt legacy types, but your insistence on member functions in monolithic classes just pushes the design away from generic-programming toward simple template trickery to have class A "mimic" class B. But past the "mimification" (sorry) is just old-schold OO programming. No, I use templates throughout to make internals generic to decrease coupling, increase modularity and improve my productivity. In particular the internals of the Booleans scanline algorithms are templated and use iterator semantics at their interfaces. The core algorithms are implemented as free functions in addition to templated parameters and iterator interfaces. The old-schold OO style is just my way of gift wrapping my code and putting a nice bow on it to make it easy for the user the use.
Please notice that the statements above clearly indicate that you are making fundamental design desicions based on the presumption of what style of API is "more natural" to the expected users base. So let me ask you this: is your intention to keep this library mainly targeted to Intel programmers? Or is the main target the C++ community at large now? If you are submmitting to boost then it ought to be the modern C+ users out there which are quite familiar and confortable with STL-style frameworks, perhaps even as much as with "old"-style non-truly-generic APIs.
To be frank, I think the developers at Intel are representative of the C++ community at large. I designed the public API for the lowest common denominator of C++ developer, not the elite. I want everyone to be able to be easily productive with the library immediately. Inside Intel the target user is the common man in a cube hacking away at C++ code, desperate to get off the critical path of a microprocessor project, and as open source it is a university student trying to get a term project or research experiment done by his deadline.
To do that I had to follow some of the conventions for how geometry type systems are expected to behave, which means no free functions. Can you explain that? Why and how are geometry type systems expected to use member functions instead of free functions?
Because the people from whom I collected requirements for the ideal computational geometry library told me that was what they wanted. They also wanted it to be generic. I wanted good encapsulation. I managed to come up with a design that did all of those things. Why would I sacrifice one requirement in order to achieve another in a different way? Luke _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost