From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2007-10-11 23:28:36
> 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
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
> by new users and target improving the productivity of my users I chose
> to follow more traditional monolithic class design style instead of
> 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
> 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
> 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
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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk