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

From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2007-10-11 19:46:11

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