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

From: Joel de Guzman (joel_at_[hidden])
Date: 2007-10-13 20:05:14

Simonson, Lucanus J wrote:
> Fernando wrote:
>> 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.
> 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?

Are you serious? It's all over the article: opt for free functions
whenever possible. In your case, you opt for member functions
always. Can you honestly say that a class with 100+ member functions
is minimal?

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

Again, I ask, aren't they familiar with STL and in particular STL
algorithms? STL algorithms are free functions. There's nothing
difficult or scary about free functions. It's just syntax.

If they are not familiar with STL algorithms as you imply, I'd say,
as C++ programmers, they better be. To be honest, I think you
are underestimating the C++ community at large if you think that
Intel is a representative of it.

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

Because there's a better way. And, IMO, it is our duty, as knowledgable
C++ folks, to educate the "lowest common denominator of C++ developer",
not to introduce various unsafe reinterpret_casts or static_casts, just
to satisfy a certain syntax style and certainly not to advocate fat
class interfaces.

Ok, I'm through with this thread. Let me end it with this with a
quote from Scott Meyers's article:

"It's time to abandon the traditional, but inaccurate, ideas of
what it means to be object-oriented. Are you a true encapsulation
believer? If so, I know you'll embrace non-friend non-member
functions with the fervor they deserve."

Think STL! Think STL algorithms! :-)

Regards
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net