Free functions versus member functions

[Kevin Bealer]

Walter Bright Wrote:

> Continuing the discussion from the thread "questions on PhanTango 'merger'":
> 
> Lars Ivar Igesund wrote:
>  > It is not as if such functions are non-existant in Tango, so which exact
>  > functionality do you think is better expressed through free standing
>  > functions rather than objects? The answers of others shows that this
>  > usually is wanted for objects where you often need only one operation on
>  > the given object, even if others are available. This don't remove the 
> fact
>  > that an object (class) equally often is a useful abstraction, and 
> when that
>  > is established, free standing functions usually should be implemented as
>  > wrappers around each method on the object, rather than the object being
>  > implemented via free standing functions. This is why Tango looks as 
> it does
>  > today; we have avoided wrappers of our own code if possible, because they
>  > degrade orthogonality of the API, and add more code to maintain. 
> Whether we
>  > have been to strict in enforcing that stance, is an open question.
> 
> I've been stumped by this design issue before. Should functionality be 
> done as a set of free functions, or as member functions? I remember 
> going over this with Matthew Wilson, and he resolved it by implementing 
> two parallel sets of interfaces: one free, the other member. I thought 
> that doing both was a copout, but couldn't figure out which one was right.
> 
> I eventually ran across this article by Scott Meyers 
> http://www.ddj.com/cpp/184401197
> which made a lot of sense. It gives some good guidelines to use to make 
> such decisions, and backs it up with reasoning that I find compelling.
> 
> Isn't it funny how we've completed the circle? We went from all free 
> functions in C, to all member functions in C++, and now back to free 
> functions? <g>

I like Meyer's point here.  My view is that classes provide the following added value: they let you define a bunch of operations without defining how they specifically will work.

The example I think of is what I believe are two mistakes in the C++ STL, the first is 'sort'.  I think it "should" be a member function, as vector::sort and list::sort have to be done differently for efficiency reasons.

They give us the efficiency by making list::sort a member and vector can be sorted with sort(v.begin(), v.end()).  But I think that's a mistake, since you can't write a good template that calls x.sort() and expect it to do the best thing.

The other mistake (I think) is in the other direction, which is the 'extra' members that classes like string and vector have that give them personalities.  For example, methods like "push_back()" and "rfind()" could be implemented externally for both string and vector, and it would result in less complexity AND more capability.  (Maybe they wanted something like Boyer-Moore for string's find() related code?)

Kevin