Re: [boost] [Review Request] Inclusion of the Boost.Polygon Voronoi Library

Subject: Re: [boost] [Review Request] Inclusion of the Boost.Polygon Voronoi Library
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2012-04-10 19:59:34

From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]] On Behalf Of Andrii Sydorchuk

>I didn't consider this before as this will require just one small change in the Voronoi builder initialization method. 
>So if this is a permanent requirement for the inclusion I'll do the proper updates. 
>On the other hand I really like current interface as it is very simple and allows to construct Voronoi diagram 
>with one include header and two lines of code. I am wondering if there is a solution that will satisfy both sides. 
>For example changing default implementation of point_traits:
...
>This will support my current template interface that accepts anything with x(), y() methods by default and 
>won't break functionality of the Boost Polygon library. Am I right?

The problem is somewhat the reverse of that actually.  People will want to use their point classes that are already model of Boost.Polygon point_concept with the voronoi diagram API and will not be able to because it expects different traits than the point_concept requires.  It is fine for the implementation details of voronoi diagram to have no coupling to the rest of Polygon (it is cleaner) but the interface should be consistent with the rest of the library so that it is easier to use.  We can wrap any model of point_concept with a type that provides x()/y() assessors and contains a reference to the original point object to satisfy the requirements of the implementation details of the core algorithm while still satisfying the requirements of the interface to conform to point_concept semantics.

Thanks,
Luke