Hi Phil,
Fernando Cacciola wrote:
Hi Phil,
In the review result announcement, Fernando listed many of my minor complaints about the library but did not address this suggestion, or the existence of GGL "in the wings", at all.
You are correct... as I said in another post I really intended to address all objections but as GGL review started I had to compromise.
I understand. I posted that comment primarily in reply to John Phillips' claim that "[we] were also all quite conscious of the existence of GGL. This existence was not considered a show stopper in any of the reviews posted".
OK
So, FWIW, I totally agreed with Luke's own response to your suggestion: that there is absolutely no need to reject Boost.Polygon as a mean to make sure GGL has a chance to be accepted.
The one thing that I could not state on my results is this: I had followed GGL from the begging, as I did GTL, and I know enough of both to be certain that both *can* coexist within Boost, even in spite of their high impedance in some region of the fundamental base level.
I'm not sure what you mean by "high impedance"...
I meant differences that are theoretically fixable but practically not quite without significant effort.
Yuk :-(
I would really like a single common set of basic concepts to code to.
I think we all do.
As I wrote in my GGL review, there are gratuitous differences in terminology like "within" vs. "contains". I have seen no discussion of whether we think this should be fixed, can be fixed, will be fixed etc. Let alone who should "cede ground" in order to arrive at a compromise, or any technical discussion of how e.g. the point concepts could inter-operate.
OK, here is another bit of the rationale I intended to include in the results: One of the things I considered when deciding on the Boost.Polygon results was the fact that the relative ordering of the reviews will neccesarily force GGL to adapat to Boost.Polygon. IMNSHO, GGL *must* adapt now and remove all such gratuitous differences and keep its own version of things *only* when there is enough justification. I do fully realized all this and considered the amount of additional work it requires for GGL. I also realized and considered that the requirement could be considered unfair. However, I don't think it really is unfair because both libraries had coexisted in parallel for years, yet they never merged before. Say I reject(ed) Polygon (GTL) then we accept GGL. Do we accept Polgon later on and require *that one* to adapt? Or do we just loose GTL for good? The way I saw it, the only way to make sure that the *community* would benefit from the best of both (and both have *great* things to offer) was to avoid rejection on the basis of future incompatibilities even at the expense of requiring the second comer to adapt back or rationally argue that Polygon should change so as to set the record that the incompatibility is considered to the Polygon's fault and justify that way the burden put on users. Accepted libraries are not set on stone. Many have evolved a long way from the fist accepted version and I don't imagine Luke erroneously believing that, since his library was accepted first, he doesn't have to do corrections on the light of GGL and for the sake of the community. If fairness is to be considered, I guess one could argue that the first one to had been ready deserved the right to set the reference. Specially if we consider that GGL was not ready for review when Polygon was, so it is not that they ended up with such a relative ordering due to arbitrary scheduling. That could have made the current GGL burden unfair, but it's not how it happened.
Personally I'm totally unmotivated to contribute to "Boost.Geometry" if I have to either do everything twice or gamble on which one is going to "win" in the end.
Of course, but rejecting one of the libraries is not neccessarily the best way to avoid ending up with competing choices. Sometimes, getting cooperation rolling requires a small push.
I would really like to see some discussion of this before this review ends, though sadly I will be going away tomorrow and may not be able to take part in much of the remaining discussion.
Changing the subject slightly, I have also wondered over the last few days about acceptance criteria. Many of Barend's emails mention things that have not yet been implemented or are planned. I wonder whether we are, or should be, judging the library in terms of what has been submitted for review, or what we believe that the authors will eventually deliver? Based on previous proposals where "fully formed" libraries have been presented, and some comments from review managers / wizards(?) that "the library being reviewed is the one submitted", I have always assumed the former. In this case, I think that some reviewers are assuming the latter.
FWIW I definitely accepted Boost.Polygon on the basis of what it is *now*, not what it could become. Yet at the same time, I also considered how, IMO, things would make sense to play out with GGL in the future, which I just outlined above. Best -- Fernando Cacciola SciSoft Consulting, Founder http://www.scisoft-consulting.com