Geometry Boost List: [ggl] combine

Subject: [ggl] combine
From: Adam Wulkiewicz (adam.wulkiewicz)
Date: 2011-02-27 09:28:05

Barend Gehrels wrote:
>> Considering the function name. If we have functions combine, connect,
>> join the order, there should be some similarity between the
>> parameters. The order doesn't matter because take similar objects and
>> return something connected/combined/joined. The next thing is that our
>> function may have the name combine or combined.
>>
>> Our syntax would look like this:
>>
>> Box combined(Geometry const & geometry, Box const& box)
>> Geometry3 combined(Geometry1 const & geometry, Geometry2 const& box)
>>
>> or
>>
>> void combine(Geometry const & geometry, Box const& box, Box
>> &expanded_box)
>> void combine(Box const& box, Geometry const & geometry, Box
>> &expanded_box)
>> it doesn't matter if the box is first or second because the result is
>> in the third parameter, something combined.
>
> Actually the current signature and behaviour is not that it combines 2
> geometries, but that it expands the box to cover the additional geometry.
>
> So the idea is to call it in a loop, see http://bit.ly/hDgUM0
> (where it is not a loop but the idea will be clear).
>
>
>
>>
>> But if we have the name corresponding to one of the objects, e.g.
>> expand, IMO it should be on the first place because the name
>> corresponds to it.
>>
>> expand(box, something);
>> box.expand(something);
>>
>> or maby
>>
>> box.expand(something1).expand(something2)
>> box << something1 << something2 ... // this looks a little odd
>
> Nice sample. Calling a method on a box is not possible for us. Because
> we're concept based and .expand is not part of our concept, and often
> not part of a legacy rectangle.

Yes, it were just examples of the way of thinking.

>
> Returning a box would be possible.
>
> box = expand(something, box).
>
> Actually this is probably better because both input arguments are const
> then. So can be reversed indeed.
>
> So something like:
> box = make_envelope<Box>(something); // determines initial bbox
> box = expand(box, other thing 1);
> box = expand(box, other thing 2);
> box = expand(other thing 3, box);
>
> One of them must be of type box otherwise... the output type is now known.

IMO code should be self describing. What I was trying to say is that if 
the function's name is a word refering to the parameter, it should be 
the first one, so:

expand(this_object, by_something_else)
void expand(Box&, Geometry const&)

or

expanded_object = expanded(this_object, by_something_else)
Box expanded(Box const&, Geometry const&)

If the order of parameters shouldn't be straightforward, function should 
have the name refering to both parameters so combine is probably better 
name, but then you don't know what this function exactly does. It should 
be the name describing that both parameters are used to create a box.

I don't have a good name but it might be something like

box = boxify(box, geometry)
box = boxify(geometry, box)
box = boxify(geometry1, geometry2) ?

Or, since there is make_envelope already

box = make_envelope<Box>(geometry)
box = make_envelope(box, geometry)
box = make_envelope(geometry, box)
box = make_envelope<Box>(geometries.begin(), geometries.end()) ?
box = make_envelope<Box>(geometries_range) ?

Personally, I'd like to have simply

void expand(Box&, Geometry const&)

but it's a matter of preference.

Regards,
Adam