Geometry Boost List: [ggl] combine

Subject: [ggl] combine
From: Barend Gehrels (barend)
Date: 2011-02-27 08:29:26

Hi Adam,

Thanks for your thoughts!

On 27-2-2011 13:17, Adam Wulkiewicz wrote:
> Barend Gehrels wrote:
>> Nearly all functions conform to the std:: library. std:: library defines
>> first input iterators, then output iterators, then other values.
>> e.g. http://bit.ly/aPh6Bv
>
> Isn't scheme used only in relation to iterators? For objects that are 
> references/pointers to some object in the collection.

Often yes. But Boost.Range does the same thing, http://bit.ly/hqNEs5

>
> E.g. streams are allways the first parameter.
>
> out& operator<<(out, data)
> in& operator>>(in, data)
> boost::asio::read(socket, data)
> boost::asio::write(socket, data)
>
> Probably because they're stand-alone objects, different from data and 
> the order is simply taken from method call syntax.
>
> stream.some_method(data);
>
> In addition to his, we could write:
>
> stream << data1 << data2 << ...
> stream.do_something(data1).do_something(data2) ...
>
> So it's natural that streams are the first parameter.

Good point.

>
> 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.

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.

>
> on the other hand
>
> Box Box::expanded(Geometry const& something) const
> Box expanded(Box const& box, Geometry const& something);
>
> But, it all depends on how we think of the box.
>
> In the computer graphics and game programming areas this operation is 
> named expanding and the box is referred as aabb (axis alligned 
> bounding box).

I know aabb indeed. Maybe expand is the best name. Thanks.

Regards, Barend

-- 
Barend Gehrels
http://about.me/barendgehrels