From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2007-10-13 02:41:31
>Do you write "implies OO" as in "implies member functions"?
>If so consider that lots of people, specially here, consider that
>free-functions are just one OO-style.
>That Meyer's article Joel pointed out explains why.
Yes, I read the Meyer's article and other similar articles encouraging
non-member, non-friend functions. I think it is safe to say that my
data structures are fully encapsulated through a minimal and sufficient
interface, the ConceptMap. In addition to that I add a minimal and
sufficient interface between the library functions in the Concept class
and the ConceptMap, allowing even the concept map to change without
needing to change my library functions. I achieve all the goals Meyer's
describes already. If I have achieved the goal already, why should I
change the code?
>Assuming you disagree, can you show us which goal(s) _need_ the
>choosed instead of the "functional" one?
Ease of use. Since my design is flexible, robust and has good
encapsulation already I have the luxury of allowing myself to provide
the "good old fashioned" style of API that my users want. If I made my
library completely different from what they used before that would hurt
uptake and slow down its penetration rate.
>Note: your library design in on the edge of not being "generic
>but merely parametrized old school object-oriented programming.
>It has some genericity scent since at least you can adapt legacy types,
>your insistence on member functions in monolithic classes just pushes
>design away from generic-programming toward simple template trickery to
>class A "mimic" class B. But past the "mimification" (sorry) is just
>old-schold OO programming.
No, I use templates throughout to make internals generic to decrease
coupling, increase modularity and improve my productivity. In
particular the internals of the Booleans scanline algorithms are
templated and use iterator semantics at their interfaces. The core
algorithms are implemented as free functions in addition to templated
parameters and iterator interfaces. The old-schold OO style is just my
way of gift wrapping my code and putting a nice bow on it to make it
easy for the user the use.
>Please notice that the statements above clearly indicate that you are
>fundamental design desicions based on the presumption of what style of
>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
>If you are submmitting to boost then it ought to be the modern C+ users
>there which are quite familiar and confortable with STL-style
>perhaps even as much as with "old"-style non-truly-generic APIs.
To be frank, I think the developers at Intel are representative of the
C++ community at large. I designed the public API for the lowest common
denominator of C++ developer, not the elite. I want everyone to be able
to be easily productive with the library immediately. Inside Intel the
target user is the common man in a cube hacking away at C++ code,
desperate to get off the critical path of a microprocessor project, and
as open source it is a university student trying to get a term project
or research experiment done by his deadline.
>> 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?
Because the people from whom I collected requirements for the ideal
computational geometry library told me that was what they wanted. They
also wanted it to be generic. I wanted good encapsulation. I managed
to come up with a design that did all of those things. Why would I
sacrifice one requirement in order to achieve another in a different
Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk