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

From: David Abrahams (dave_at_[hidden])
Date: 2006-09-27 15:03:44

Oleg Abrosimov <beholder_at_[hidden]> writes:

>> You're not saying what you mean by "reuse."  We think reuse is very
>> possible with the Parameter library, so it's quite unclear what you
>> might be referring to.
>
> libraries are all about reuse. boost::parameter is not an exception of 
> course.
>
> By reuse I mean configuration reuse in client code. 

By "configuration" I take it you mean something equivalent to
"ArgumentPack."

> Not reuse of 
> boost::parameter library in other libs.
> Consider:
> foo(width = 2, height = 1);
> // ... some code ...
> foo(width = 2, height = 3);
>
> vs.
>
> TFooParam p;
> p.width = 2;
> p.height = 1;
> foo(p);
> // ... some code ...
> p.height = 3;
> foo(p);
> // p is reused here

That's also possible with the parameter library; p would be an
ArgumentPack.

> The drawback in such a scenario is reduced visibility, because of 'p' 
> can be initialized too far from the second call of 'foo'.
> But in practice most common scenario is to initialize 'p', call 
> 'foo(p)', then modify 'p' slightly and call 'foo(p)' again. It means 
> that visibility is preserved.

Is that common?  For what interface?

>>>   - ambiguity with other language constructs
>>>   (it is very important drawback. As I realized from parameter docs, 
>> 
>> You're not being specific enough here either.  I can't imagine what
>> ambiguity you mean.
>
> consider:
>
> void new_window(char const* const, int = 10, bool = true);
>
> int main()
> {
>      int width;
>      bool titlebar;
>      new_window("alert", width=10, titlebar=false);
>      return 0;
> }
>
> call to new_window can not be translated unambiguously by reader in 
> presence of named params. I expect that compiler will complain, but 
> reader can be fooled by such a call, especially if we change it a bit:
>
> int main()
> {
>      new_window("alert", width=10, titlebar=false);
>      return 0;
> }
>
> What is a 'width' here? parameter name? or some variable in global scope?

Oh, sure, Fred Bertsch's problem.  Because of that we instituted a new
naming convention (and associated macros for defining keyword
objects).  Now that would read:

  new_window("alert", _width=10, _titlebar=false);

>>> great effort should be made to make such an ambiguity possible. 

Why would we want to make an effort to enable ambiguities?

>>> 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)
>> 
>> It's unclear what you mean.
>
> I mean that significant amount of work should be done to allow named 
> parameter syntax that can be ambiguous as was shown above. 

Why should it?

> The idea I was trying to explain is simple - May be it is possible
> to find a way to achieve both goals - unambiguity and reduce of
> efforts required to enable named params usage.

I think a suitable naming convention is enough.  Or you can use
qualification to refer to parameter names.

>> IMO the implementation complexity doesn't matter as long as it works
>> and gives comprehensible feedback when misused.  Do you inspect the
>> source code of your compiler and complain about its implementation
>> complexity?
>
> We are living in very different worlds. and it is good for you. I'd
> be happy if I can say the same as you've said here.  Not many of as
> are paid for libraries writing. My job is application
> programming. It is always done in a high time pressure.

That's why you need libraries that work reliably.

> I'm writing several functions per day. Most of them are used only by me 
> to implement other functions. I _can not_ spend time to implement named 
> params for each function that I wrote. 
> It is completely impractical. 

I agree in principle that it makes little sense to use named
parameters in all your internal interfaces.  

But note, defining a parameter-enabled function hardly takes any time
anymore, since Daniel W. created the new macros described in
http://www.boost-consulting.com/boost/libs/parameter.  It's almost the
same as writing down the function would be if there were a built-in
language feature.

Cheers,

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