Boost logo

Boost :

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
>> 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at