Re: [boost] GGL Review

Subject: Re: [boost] GGL Review
From: Barend Gehrels (barend_at_[hidden])
Date: 2009-11-26 07:19:22

Hi Gordon,

Thanks for your review!

>
> My main concern is the number of things which are incomplete.  
> Certainly the obvious lackings such as missing boolean operations, 
> clockwise versus counterclockwise polys, closed versus open polys, 
> should be fixed or rationalized before this is released.  It sounds 
> like Barend and friends have promised to complete all of these things.
Yes, these things fit in a generic library. There were more comments on 
completeness. A library as this one is maybe never complete. But things 
considered as basic should be included.
>
> I'd like to see GGL run with Boost.Polygon's robustness tests and 
> randomly generated efficiency tests.  It sounds like this has already 
> begun.
> A couple of people asked for GIL examples.  This would require a line 
> and curve bitmap rendering library, which would be a really cool 
> addition to Boost.
We will indeed test with random tests, robustness tests and a GIL 
example (somehow using a GIL extension?) would be very cool indeed! But 
this requires efforts from the GIL team or contributors as well...

>
> It seems very well thought out, for the domain which has been explored 
> so far.  The only concern I have (which I haven't thought out 
> thoroughly) is the absence of hierarchical concepts.  IIUC a new class 
> must subscribe to all concepts, not just the most derived.  This seems 
> like it might get onerous when there are a lot more concepts / if the 
> granularity is reduced.
This has been discussed earlier on the list, so I give here the link 
with the explanation.
http://article.gmane.org/gmane.comp.lib.boost.devel/187452

>
> >From the discussion and from the presentation at BoostCon, I 
> understand that not everything which is described is implemented, and 
> everything which is implemented does not completely live up to the 
> standards which the library sets.
>
> Again, I think these discrepancies should be resolved either by 
> implementation or by narrowing the scope and documenting.  As is, it's 
> rather confusing.
We agree here. The realm is large, it is an ambitious project. All 
functionality, and within all functions all geometry combinations, 
should and will be documented.
About the doxygen, that will be left, we agree with you (and all other 
reviewers).

Regards, Barend