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

From: Doug Gregor (dgregor_at_[hidden])
Date: 2004-11-24 11:50:03

On Nov 23, 2004, at 1:00 PM, Gennadiy Rozental wrote:

> "Doug Gregor" <dgregor_at_[hidden]> wrote in message
> news:0BBD3222-3D6E-11D9-9E8D-000A95B0EC64_at_cs.indiana.edu...
>> 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.
>
> Does this mean that you agree that submitted library does not provide
> "more-capable" interface?

I do not agree and it is not relevant. If you want to talk interfaces, 
then talk interfaces: alternative implementations of a library are not 
to be the focus of a review.

> The only exclusions where we may share the keywords are cases with 
> series of
> related function. For example different constructors for the same 
> class or
> different access methods within same class e.t.c.

> All of that is escalated by what submitted solution propose in regards 
> to
> type enforcing:
>
> struct f_keywords : keywords<
>               named_param<
>                  name_t
>                , boost::mpl::false_
>                , boost::is_convertible<boost::mpl::_, std::string>
>
> This interface is way too verbose IMO for the basic, but most widely 
> needed,
> type enforcing feature.

So use a typedef or create a metafunction. The important part of a 
general mechanism is that it can be used for many specific cases. If 
you want an additional interface for a typed keyword (or other such 
shortcuts), ask for it.

>> 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.
>
> This maybe the case would we were discussing named parameter feature 
> for
> inclusion into language support. As it stands now, until we have 
> template
> functions with variable length parameters list, the only viable option 
> (IOW
> best for the user) IMO is single function interface. In theory I still 
> would
> prefer single function interface:
>
> template<typename T[]>
> void foo( T[] const& params ) {
>     std::cout << params[name] << params[value];
> }

Everyone would prefer a single function interface. The library authors 
even provide a macro that makes the implementation look like it is 
providing a single function interface even when it can not be 
implemented as such.

        Doug