Re: [boost] Proposal/InterestCheck: Boost.Geom

Subject: Re: [boost] Proposal/InterestCheck: Boost.Geom
From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2009-01-29 12:30:47

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.