Re: [boost] Formal review for QVM

Subject: Re: [boost] Formal review for QVM
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2015-12-13 09:43:36

Oswin Krause wrote:
> We encourage your participation in this review. At a minimum, kindly
>> state:
>> - Whether you believe the library should be accepted into Boost
> Not now, but at a later point surely.
>
>>   * Conditions for acceptance
> This is not because the library is not relevant or useful, or because 
> of bad design, but because it misses important functionality in the 
> current state that would give it impact in the current ecosystem. "If 
> I already have to use two competing point libraries, why should I 
> additionally introduce qvm?"
> The scope must be broadened by including some advanced algorithms 
> which make qvm useful in the ecosystem, also interoperability with 
> already existing boost components must be established. Some of its 
> functionality already exists in boost, which makes acceptance as a 
> standalone library a bit odd. It could be worthwhile to merge qvm with 
> another geometry related boost library to strengthen the links between 
> the libraries.

Thanks!

Do you vote for conditional acceptance under the condition that in 
addition to basic operations also more advanced algorithms should be 
implemented in the future? Or that the library shouldn't be accepted at 
this point?
Emil are you willing to extend the scope of the library?

I'm guessing that if Emil wanted to implement some advanced algorithms 
from some specific domain he'd be forced to redesign parts of the 
library, e.g. represent data in a different way, provide specialized 
containers, etc. It's also possible that this approach would be 
incompatible with some other one suitable for a different domain. And 
this is the reason why QVM is implemented on a high level of 
abstraction. So it may be used as a link between various domain-specific 
libraries. Is that correct?

Adam