Re: [boost] Boost.MPI accepted

From: David Abrahams (dave_at_[hidden])
Date: 2006-09-22 01:04:44

"Robert Ramey" <ramey_at_[hidden]> writes:

> Jeremy Siek wrote:
>
>> [suggestions]
>> 1. Named parameters in the interface
>
> One tiny observaton.  The suggestion of named parameters for the interface
> could well be applied to many if not most if not all libraries.  

I doubt the suggestion can be made as convincingly in most cases.  It
makes sense where you have many functions with either:

  a. many parameters with the "same" type (e.g. all integral), so you
  really want to distinguish them by name because the typechecker
  won't prevent you from getting the order wrong

  b. many parameters with useful defaults and no linear ordering
  dependency among them.

In other cases, it provides less benefit.

> Could this not be considered as a separate orthogonal layer to the
> current interface?  This would
>
> a) make the named parameter interface available where convenient

OK, good idea.

> b) make it optional rather than obligatory

I don't understand; It's already optional.

> c) set the precedent for other libraries which might benefit
> from a named parameter interface - without the need to
> re-do any of the library itself.

You don't need to "re-do the library."  It's a trivial
transformation to add a named parameter interface to an existing
function.  Just rename it slightly or put it in a detail namespace and
dispatch to it from the named-parameter-enabled function that uses the
implementation function's original name.  To clients of the original
function, there's practically no detectable difference.

> Perhaps there could even be a convention such as
>
> boost/named_parameters/date_time.hpp ...
>
> or perhaps
>
> boost/date_time/named_parameters.hpp

I understand why we want to do that for, e.g., Python bindings.
Having Python installed and linking with it is a responsibility nobody
wants to accept unless they need Python.

Using Boost.Parameter is not the same sort of thing; it comes with
Boost and is transparent to build/configuration issues.  I'm not
saying what you're suggesting is a bad idea; I just don't see what
great advantage it offers.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com