Re: [boost] [GGL] Bost.Polygon (GTL) vs GGL - rationale

Subject: Re: [boost] [GGL] Bost.Polygon (GTL) vs GGL - rationale
From: Jose (jmalv04_at_[hidden])
Date: 2009-11-16 12:28:22

On Mon, Nov 16, 2009 at 2:41 PM, Brandon Kohn <blkohn_at_[hidden]> wrote:
> Jose wrote:
>  > 5) Boost failed to set the scope for a geometry library/ies and
>>
>> created tension with candidate library authors
>
> I agree with this. I think that in the rush to get their own vision of a
> geometry kernel accepted, all the geometry authors let go the notion of
> having a single common representation for each geometry type. Unfortunately
> as can be seen from the discussions about geometry there hasn't been
> consensus on much of anything. Well, beyond the more trivial things like
> agnostic compile time access to coordinate sequences (the bicycle shed.)

It seems logical the authors will always try to push their library but
it should be a separate discussion (maybe before the review process)
that clarifies what boost wants and doesn't want. I think this
discussion is necessary now because the early boost libraries had a
narrower scope but the newer ones are much broader in scope.

>> Clearly there was no consensus in this library, and no clear
>> discussion if one single library was possible (I understand your
>> points that multiple libraries in this case may be preferable but
>> still that is not incompatible with a complete design discussion)
>
> I did vote that Polygon should be accepted and still believe it should based
> on its merits. I should note that subsequent disagreements have already come
> about WRT how data structures are different between GGL and Polygon
> (specifically the way polygons are defined). Clearly the community has so
> far failed to produce a way of defining geometry in a form that arguably
> should be common for all geometry libraries. I suspect this happens because
> most of the authors have the goal of adapting long term projects into a
> Boost library rather than building a common one from scratch. I suppose the
> question is whether the community should be reinforcing this practice?

Yes, your description explains it nicely ! Now is the time to update the way the
process works so that we don't get into this mess again. The logical
steps I see are:

1) Is it possible to have an encompassing library ("generic") that can
accept multiple geometries and algorithms ?

2) If no, then have separate libaries
    Else, then take the most generic base and try to make sure
multiple application domains are happy.

This is the theory, but in practice, when the library being proposed
by corp authors (instead of typical boost case of individual authors)
then there is little incentive to cooperate but the community should
have clear guidelines about this.

If it were my decision, I would withdraw the just accepted library
because of the faulty review and to set a precedent. But it's really
hard to walk backwards to walk forward later on!

> Regards,
>
> Brandon
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>