Anis Benyelloul wrote:
My purpose is to make the indirect approach as/more readable and convenient as the direct one so that the user's won't have to tie their code to the underlying framework's points and boxes (i.e they won't have to deal directly with QPoints at all).
It seems that your [Barend's] purpose is rather: Provide lots of algorithms and make them applicable to any type the user is currently working with (the user will still have to know/use QPoints before passing them to the algotithms).
When I first talked about geometry on this list I felt much the same as you (Anis) about this particular choice. Others (including Luke) felt that providing a library that users could apply to their "legacy" code was important. I think I have now come around to that point of view: a boost geometry library shouldn't try to be a "master library" that hides all other libraries' interfaces, but rather it should be an "equal player" that can inter-operate with other code in whatever style the user wants. My remaining concern about this is that it makes things more complicated: some of Luke's messages, for example, go way over my head! But as I said before, these details are less important than the question of functionality: once I've wrapped up my GUI library's points (etc), what can I actually *do* with them? Provide us with some compelling algorithms (etc) and then we'll go along with whatever stylistic decisions you have made. You asked about previous submissions. Barend and Luke replied; there has been one other recent one, by Brandon Kohn, announced here: http://thread.gmane.org/gmane.comp.lib.boost.devel/180334. This has the disadvantage compared to the other two of a lack of documentation. Cheers, Phil.