Re: [boost] Named params (was Re: Boost.MPI accepted)

From: Oleg Abrosimov (beholder_at_[hidden])
Date: 2006-09-25 11:20:15

Hello David,

As a result of this discussion I've read boost::parameter docs 
completely. And now I want to apologize for my aggressive post. This 
library is very sophisticated.
Nevertheless, I didn't become it's proponent and there are some thoughts 
  about the overall function parameters problem that can be useful for 
this discussion:

  1) parameter's type is not a panacea
It means that giving function parameters unique types can solve the 
problem of mistakenly swapping them, but is not always applicable, 
sometimes impractical, doesn't solve problem with optional parameters, etc.

  2) many parameters:
  - some are mandatory and
  - some are optional with default values supplied

It means that both optional and required parameters should be taken into 
account.

Definition:
  configuration - is a set of parameters for a given function
  f1(configuration);

Requirements for ideal solution of implementing and using function's 
configurations:
  1) simple implementation of configuration and function that uses it
  2) maximum maintainability
  it means:
  a) configuration parameters should be specified as close to
     function call as possible
  b) configuration parameters should be visible (names)
  c) configuration reuse

  solutions:
  1) positional function parameters
  + mandatory parameters
  + optional parameters
  - invisible parameters
  - interference of optional parameters complicates its usage
  - reuse is not possible
  + no ambiguity with other language constructs
  + implementation is simple

  2) named parameters
  + mandatory parameters
  + optional parameters
  + visible parameters
  - reuse is not possible (it is not _very_ important, but important. Is 
there a way to extend parameter lib to support such a reuse?)
  - ambiguity with other language constructs
  (it is very important drawback. As I realized from parameter docs, 
great effort should be made to make such an ambiguity possible. It would 
be better IMO to eliminate this efforts in implementation and the 
ambiguity in one shot - provide special may be auxiliary structure - 
like syntax to use parameters)
  - implementation is not simple
  (really. all this nightmare can be done for library that is created 
once and used many times, but I need a tool that can be used on a daily 
basis for ordinary code. it means that simplicity of an implementation 
should be very close to the solution with auxiliary structures below)

  3) auxiliary structures
  - mandatory parameters
  + optional parameters
  + visible parameters
  + reuse is possible
  + no ambiguity with other language constructs
  + implementation is simple

The last approach with auxiliary structures has only one drawback - it 
is not possible to have required parameters with it. May be you, David, 
can see a way how parameter lib can be reused/extended into something 
like the las solution, but with all '+' marks?

( I remember additional arguments by Michael Walter:

a) parameter values are copied
b) parameter values need to be default-constructable (into a valid state)

but they are not important for me just now
)

May be the best solution that we can have now is:

//implementation:
BOOST_PARAM_STRUCT_BEGIN(TFuncParams)
BOOST_DECLARE_PARAM_OPTIONAL(type1, name1, def_val1)
BOOST_DECLARE_PARAM_REQIRED(type2, name2)
BOOST_DECLARE_PARAM_OPTIONAL(type3, name3, def_val3)
BOOST_DECLARE_PARAM_OPTIONAL(type4, name4, def_val4)
BOOST_PARAM_STRUCT_END()

void func(TFuncParams const& params)
{
     cout << params.name1;
     // etc.
}

usage:
BOOST_INSTANCIATE_PARAM_STRUCT_BEGIN(TFuncParams, params)
BOOST_PARAM_OPTIONAL(params, name1, val1)
BOOST_PARAM_REQIRED(params, name2, val2)
BOOST_INSTANCIATE_PARAM_STRUCT_END()

func(params);

The idea is that all boost::parameter magic is hidden by those macroses. 
The question is - can it be really done?

Oleg Abrosimov.