Re: [boost] Re: Re: Named params lib review

From: Doug Gregor (dgregor_at_[hidden])
Date: 2004-11-23 11:38:03

On Nov 23, 2004, at 9:37 AM, Gennadiy Rozental wrote:
> "Doug Gregor" <dgregor_at_[hidden]> wrote in message
> 1. It really trivial to implement the restriction on public level:

Ok.

>> Granted, your typed_keyword permits earlier detection of certain 
>> typing
>> errors. For instance, if I try to write "name = 5", your library will
>> abort the compilation at that expression but the library under review
>> will instead remove "f" from the overload set if it is called. 
>> However,
>> there is a potential price to be paid for this earlier checking: the
>> name "name" has now been reserved for string parameters and cannot be
>> reused without introducing a new "name" keyword in some other scope
>> with a different type.
>
> 1. That is not true. Nothing prevent me from introduction of keyword 
> name in
> different namespace/compilation unit. Actually in most cases I use 
> keywords
> with namespace qualifiers: sock::name, cla::name, factory::name e.t.c.

Precisely why I wrote "in some other scope", which refers both to 
different namespaces and different translation units :)

> 3. IMO It's bad idea to introduce global keywords used by various
> independent functions for different purposes and different data types. 
> For
> example:
>
> new window( size = make_pair(10,20) );
> new listbox( size = 10 );
> new Jeans( size = "36x30" );
> new Bowl( size = 5.675 );
>
> I don't see above as a good practice and library shouldn't encourage 
> it.
> Instead one should either use difference namespaces (see 1) or 
> different
> keywords: dimensions, size, cloth_size, volume.

Why is a listbox so important that it gets the short name "size" 
whereas the jeans get the longer name "cloth_size"? The example is 
good, but I don't think it strengthens your position at all. On the 
contrary, we see that "size" means very different things when talking 
about listboxes vs. when talking about jeans, but the word is not 
ambiguous in the context of each line.

>> My (subjective) expectation is that a library
>> may start by using typed keywords, but as the library evolves and more
>> functions gain named parameters I'd expected those typed keywords to
>> become non-typed keywords. There is no place in the BGL, for instance,
>> where I would consider using a typed keyword.
>
> That Ok. Unfortunately I am not that familiar with library but I do not
> believe BGL is the best example. BGL is template based library 
> solution. In
> an end user's code my expectation is that in most cases one would use 
> typed
> keywords.

The BGL is _an_ example, but clearly not the only one. However, it does 
have the advantage of having had a named parameters mechanism for the 
last several years, so in my mind it carries significant weight  
relative to hypothetical usage scenarios.

>> Another subjective difference between the two is in the call to "f".
>> The library under review supports the syntax:
>>
>>     f(name = "wibble", value = int);
>>
>> whereas, as I understand it, your library supports the syntax:
>>
>>    f((name = "wibble", value = int));
>>
>> I'm not going to weigh in on this issue.
>
> Submitted library allow both syntaxes. I would never use first though. 
> In my
> experience named parameters interface is most valuable facing numerous
> optional function arguments. Why would I want to provide 10 overloads 
> for
> the same functions with different number of arguments, where 1 
> suffices?

You are asking the wrong question. The right question is "which syntax 
is better for users?" Step back from the implementation, the language, 
and the limitations of both and determine what syntax you would like to 
use when calling these functions. Implementation details are secondary 
to interface details.

        Doug