Re: programming guidelines, prefer free functions

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-17 11:18:13

--- In boost_at_[hidden], David Allan Finch <sarum_at_v...> wrote:
> jsiek_at_l... wrote:
> 
> > I have a suggestion for the boost programming guidelines.  As 
various
> > boost members have pointed out in the past (most recently Dave), 
it is
> > better to use free (non-member) functions over member functions in
> > public interfaces.
> 
> I am probably a lone voice in the wilderness on but I
> view that Coplin's (?) original analysis of this problem
> is incorrect and hence his derived solution is incorrect
> to.
> 
> His premises is that if you have a complex class you
> can't extend it because you do not have access to
> the fundamental fields. Hence it is better to have
> access  to a smaller set of methods and
> have complex functionality at namespace level.
> 
> This is an incorrect (IMHO) conclusion. If you
> look at any real world physical implementation
> of a system, you will find that the complex functionality
> is rapped up in a new level of system. I.E. controllers.
> 
> One of the classic problems that is used to show
> why there is a problem is extending the String
> class. IMHO the problem is that the String
> class is to complex and should have been implemented
> as a controller of a StringBuffer. You would then
> write your own String Manipulator or extend String
> to change the String Buffer how you wished it to be
> modified.

I'm not sure that I understand fully all the pros and cons on this 
subject.  However, the last paragraph here is precisely why I'm not 
sure that I agree with the original hypothesis.  The string class as 
an example is not a very good example.  It isn't difficult to 
extend.  It's just problematic to extend it via inheritance, which is 
what Jeremy suggested was the only solution.  Instead, you extend it 
through free standing functions.  This is *precisely* what the STL 
algorithms do, though they were carefully constructed to be generic 
enough to extend a large class of objects instead of a single object 
type.

The inheritance/wrapper (containment) approaches are only appropriate 
if you actually need to extend the class by adding data or need to 
use the derived type polymorphically.  Neither of these cases are 
going to be solved by preferring free standing functions over member 
functions to begin with.

I'm not at all against using free standing functions, but I've yet to 
be convinced that we should prefer them over member functions.

William Kempf