Simonson, Lucanus J wrote:
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.
Ok, that's it. The question I really was waiting for an answer is: what is the need for this elaborate dance? Now Luke confirms it: the source of all these complexity is their requirement to use member functions everywhere. Luke mentioned "a gratuitous, rich, and highly productive API "with more than "a hundred member functions plus stream operators" Oh my. That's really gratuitous and not to mention obese. Instead of opting for the tried and true STL style generic programming where we have various classes that are models of various concepts plus a set of algorithms that work on these classes, the author(s) chose to shove all those Point algorithms as member functions in the "ConceptMap". Example: double d = p1.euclidieanDistance(p2.transform(t) - p3); Instead of: double d = euclidieanDistance(p1, transform(p2, t) - p3); which is more STL style. To my understanding, the requirement to use member functions everywhere would indeed call for an elaborate scheme to provide genericity from an adapter class that masquerades as its adaptee since there is really no real proxy mechanism in C++. My response: wake up! We are not in the 80s. The STL style of programming has been with us since the 90s. This is the style of programming that Boost advocates. This style of programming can cater to a diverse set of problems and *CAN* address all your requirements. OO does not imply the dot notation. It's just syntax! I'll be aghast if your programmers are not familiar and have never used STL algorithms. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net