Fernando,
But there are lots of people using way "A" and you come in with *your* way "B" (or should that be "L" ;) I'm OK with innovation, but you do need to show us why B is better. Or at the very least, why isn't it worse.
If I had the same design goals as you, I would hope we would come up with the same solution: the best solution. If I had the same design goals as you and I come up with a radically different solution and everyone already agrees your solution is the best, I either have to convince everyone mine is best, or admit failure. If I had *different* design goals I would expect my solution to be different and the whole argument about better or worse solution goes out the window and we instead need to figure out if I had the right design goals, are your design goals better than mine and under what circumstances. My design goals in order of importance: #1 Low barrier to adoption a. Ease of integration into legacy geometry type systems b. New users must feel comfortable with the API (implies OO) c. Header file only implementation so that there is no link hassles d. No external dependencies, compiler provided library/STL usage only #2 Application developer productivity for users of my library a. API must be object oriented b. API must be intuitive eg: functions that modify an object are named with a verb functions that return an object are named with a noun functions returning a bool are named with an adjective c. API must not be error prone: correctly manage class invariants to minimize side effects fulfill the implicit contract that the API specifies d. Application code implemented using the library can be minimal in line count clear and self documenting implemented at the highest level of abstraction possible #3 Performance Lots of considerations here, not yet brought up, but believe me you will be giving me some pointed feedback once you see the code. #4 Maintainability Introduce abstraction to decrease coupling and improve modularity Generic programming applied internally and not just at interfaces Aggressive refactoring #5 Portability Must work with all reasonable compilers and OS's in both 64 and 32 bit platforms and 64 and 32 coordinate data. #6 Thread Safe (Implied in part by header file only.) #7 Safe for use before opening brace of main (for my users who didn't listen when I told them not to do that...) Obviously if using boost to its fullest were a design goal instead of avoiding external dependencies I might have done things somewhat differently. Also, because I wanted to ease the adoption of the library by new users and target improving the productivity of my users I chose to follow more traditional monolithic class design style instead of the new free function style and make the amount of work they needed to do to use and understand how to use the library as small as possible. For users that use my built in types there is practically zero learning curve. For users that adapt their own types there is a modest learning curve and minimal implementation effort required to partially specialize the ConceptMap class for each. Because the adaptors are grouped together as static member functions of a class it is very obvious what I expect the user to provide. In short, my goal was to integrate into and extend the legacy geometry type systems of as many legacy applications as possible as quickly as possible with the minimum of effort and complaining from new users so that they could start realizing the performance and developer productivity benefits that my library provides. 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. For me it is well worth it. Luke