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

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2007-10-11 23:28:36

Hi Lucanus,

> b. New users must feel comfortable with the API (implies OO)

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.

> [goals snipped]

If "implies OO" is not a synonynm for "member functions" then I can come up 
with a design that meets every single goal listed, to the letter, yet 
following the conventional BGL-style (which is actually rooted in the STL 
style... the BGL just improved it)

Assuming you disagree, can you show us which goal(s) _need_ the approach you 
choosed instead of the "functional" one?

Unless you consider member functions and "old school" OO-style a goal in it 
self.

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.

>  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

What makes you think this actually eases the adoption by new users?

Because is "more traditional"?
If it *still* where, you would have a point. But it isn't. The now 
traditional approach is the STL approach (it's more than a decade old!)

> 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. >

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 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?

Fernando