Geometry Boost List: [ggl] combine

Subject: [ggl] combine
From: Bruno Lalande (bruno.lalande)
Date: 2011-03-01 07:53:48

Hi,

I agree with Barend's conclusion, and with Adam's arguments about the order
of parameters. A few additional notes:
- As Adam pointed out, we should only follow the STL-like order of
parameters for iterator/range based functions. And I think we should even
limit that to the cases where the output parameter is a "pure output". In
the case of combine, it is an output AND an input, so we're not really in
the same situation as with all the STL functions' "output iterators". Here
were are simply modifying something according to something else, not
producing something new. Pretty much like the std::remove algorithm, which
takes in/out-put iterator first, then the object that will serve as a guide
to modify the sequence. So we are aligned.
- Other examples of output being first can be found in the Range_Ex library
=>
http://boost-sandbox.sourceforge.net/libs/range_ex/doc/html/range_ex/reference.html#id4574945
- If we were to do that, we would have to modify the arithmetic functions
the same way. This would be tricky especially with minus and divide
operations: having the left operand on the right would be quite
counter-intuitive.

For all those reasons + the ones already given, leaving the order as it is
is better IMO.

As for renaming, agree 100% as well, as I actually had troubles myself
remembering about what this algorithm does. Only when I read Barend's
"extend" proposition, I remembered. Which clearly demonstrates it's a better
name.

Regards
Bruno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20110301/27f4136f/attachment.html