Re: [boost] Re: string algorithms review

From: Pavol Droba (droba_at_[hidden])
Date: 2003-10-25 16:31:05

On Sat, Oct 25, 2003 at 09:20:12PM +0100, Paul A. Bristow wrote:
> 
> 
> | -----Original Message-----
> | From: boost-bounces_at_[hidden]
> | [mailto:boost-bounces_at_[hidden]]On Behalf Of Pavol Droba
> | Sent: Friday, October 24, 2003 3:31 PM
> | To: Boost mailing list
> | Subject: Re: [boost] Re: string algorithms review
> 
> | > 2  The suffix should be _copy and _copyto.
> |
> | Why? Could you plese provide rationale for this.
> |
> 
> Because it is shorter and  if the code is trim_copyto(s) is reads as though the
> 'to' means it goes to s.

what about meaning 'trim' the 'copy' -> trim_copy

> (Of course, a rational language would specify in, out, or in&out but I won't
> stir that hornets nest again!)
> 
> But actually I really rather like Rob Stewart's trimmed' suggestion.
> 
> Both
> 
>    std::string t(trimmed(s));
> 
> or even if t already exists (poor but what novice and ex-C programmers may do)
> 
> 	t = trimmed(s)
> 
> seems to me to imply that nothing is done to s.
> 
> But to_uppered(s) or uppered is not so nice, but still just OK?
> 
> And what about concatentation t += trimmed(s);
> 
> and addition string full_name = trimmed(forename) + substr( trimmed(surname); ?
> 
> Since we already have protection against misuse,
> this seems quite attractive to me.
> 

I have some counterarguments. 

- It is possible to used _copy as a convention for every algorithm in the library. 
- for trim and trim_copy, it is obvious, that they are variant of the same algorithm.
  It is not so obvious for trim and trimmed.
- If we adopt the convention you are proposing, it could be quite chalenging
  to makeup the names for algorithms like replace_first ( ?first_replaced? ) or even worse,
  replce_all_regex.
  When names are concatenated from multiple words, adding a suffix, does not break anything,

- This convention is backedup by STL, so people are used to it.

Regards,

Pavol