From: Robert Ramey (ramey_at_[hidden])
Date: 2006-09-22 11:37:31
David Abrahams wrote:
> "Robert Ramey" <ramey_at_[hidden]> writes:
>> b) make it optional rather than obligatory
> I don't understand; It's already optional.
>> c) set the precedent for other libraries which might benefit
>> from a named parameter interface - without the need to
> You don't need to "re-do the library." It's a trivial
> transformation to add a named parameter interface to an existing
> function. Just rename it slightly or put it in a detail namespace and
> dispatch to it from the named-parameter-enabled function that uses the
> implementation function's original name. To clients of the original
> function, there's practically no detectable difference.
OK - I understood that the suggestion was to replace the public
interface with a parameter based one. So, once it is
characterised as an optional add-on then it raises the
question as to why the same idea shouldn't be more widely
applied. That is what I meant.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk