Re: [boost] [GTL] - geometric template library - determininginterest

From: Joel de Guzman (joel_at_[hidden])
Date: 2007-10-11 20:49:04

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