|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2003-10-20 03:27:20
Pavol Droba <droba_at_[hidden]> writes:
> On Sun, Oct 19, 2003 at 04:28:18PM -0400, Beman Dawes wrote:
>> At 09:06 AM 10/19/2003, Thorsten Ottosen wrote:
>>
>> For example, the current Standard Library mutating algorithms [25.2] use
>> three techniques which tend to alert users to their mutating nature:
>>
>> 12 have "result" arguments
>> 12 have void returns
>> 7 add "_copy" to the name
>>
>> Four use more than one of the above techniques.
>>
>> When looked at from that perspective, the std mutating functions which
>> don't offer some form of clue (remove, unique, partition, stable_partitiou)
>> seem deficient.
>>
>> I definitely think the string_algo interfaces should be revised to reduce
>> the chance of misuse.
>>
>
> Looking the the list of techniques used by STL, only the last one is suitable for
> string_algo. First two disallow chaining, which is IMHO an important feature.
>
> One, quite important aspect of the string_algo algorithms is that they
> are by nature mutating. So I think, that it is natural to assume, that the basic
> variant does the mutation. Also, mutating algorithms tend to be more efficient,
> therefore they should be used as a primary option.
Some possible syntaxes:
mutate(s) % trim(3,12), blah(whatever), foo(bar)
mutate(s) = trim(3,12), blah(whatever), foo(bar)
s ^= trim(3,12), blah(whatever), foo(bar)
s = trim(3,12), blah(whatever), foo(bar)
There are about a billion possible variants which give the mutation
clue and still allow chaining, etc.
> A agree, that the "clue" is important, but isn't an existence of a _copy variant
> also a kind of "clue".
> Currently there is one convention used in the whole library. If this
> convention would be explicitly stated in the docs and stressed
> enough, if could still be bearable.
>
> In case that these arguments are not convincing enough, I would vote
> adding _inplace to mutating variants, and removing _copy. But keep
> in mind, that such a convention would lead unexperienced programmers
> to use less efficient variants of algorithms.
I prefer taking advantage of syntactic sugar in this case. If
chaining is important, it's an indication that a domain-specific
(embedded) language is called for.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk