[boost] QVM Review

Subject: [boost] QVM Review
From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2015-12-16 15:26:05

Dear All,

This is my review of Emil Dotchevski's QVM library.  Thank you to
Emil for offering this code.  I believe that Boost and/or the
standard library would benefit from vectors and matrices.
Unfortunately I don't think that this proposal is what is needed,
and I feel it should not be accepted.

I have previously posted my thoughts about the terseness of the
identifiers used and the use of operator,; I won't repeat the
details here but in summary I find the syntax not to my taste,
and not suitable for "public" code.  Boost should aim to promote
best practice, and I think this library falls short.

Now, it's not unusual to find libraries that have interfaces that
we don't like.  Often we'll use them anyway because the features
that the libraries provide outweigh the pain of using them.  Does
this apply in the case of QVM?  Actually since first looking I've
found that it does have more functionality than I thought - for
example, I've only just found that it has functions to create
matrices representing rotations (but not any other affine
transformations) and to compute the inverse of a matrix (but not
the determinant).  But there's still not enough meat here for me
to think it's worth using.  If this were a comprehensive matrix
algebra library, or a computational geometry library, or a SIMD
library, then it might be worth putting up with the syntax.  But
it isn't, it's just a medium-size collection of operators and
functions for quaternions, vectors and matrices that many projects
will already having amongst their own local utilities.

What it does offer is the ability to wrap existing matrix and
vector classes and use a single unified syntax for all of them.
It's just a shame that the single unified syntax is not the one
I want to use!

It is interesting to contrast QVM with Boost.Polygon and Boost.
Geometry. The similarity is that both of these also wrap existing
classes (for e.g. points) by traits class specialisations.  When
these were reviewed we discussed extensively how support for this
compromised the friendliness of the syntax, i.e. the need to
write get<0>(p) rather than p.x.  What we ended up with there was
I think the best that we could do, and it was probably worthwhile
because of the substantial core functionality of each of those
libraries.  In my opinion, QVM doesn't reach that threshold.

To address some of the "standard questions": I've not looked at
the code, only the docs; I've spent a couple of hours this time
and also looked when it was first proposed; and yes I do use
vectors and matrices in my own code, for various graphics and
cartographic purposes.

Regards,  Phil.