Now that the documentation of public export of private modules is inlined on the exporter's
documentation, there is non need to export anything but the `na` module.
This is to make people prefer the functional style.
Things like `a.dot(b)` dont make sense per se (there is no reason for `a` to have a different
status than `b`). Using static methods avoid this.
In-place methods are left unchanged.
Before, it was too easy to use an out of place method instead of the inplace one since they name
were pretty mutch the same. This kind of confusion may lead to silly bugs very hard to understand.
Thus the following changes have been made when a method is available both inplace and out-of-place:
* inplace version keep a short name.
* out-of-place version are suffixed by `_cpy` (meaning `copy`), and are static methods.
Methods applying transformations (rotation, translation or general transform) are now prefixed by
`append`, and a `prepend` version is available too.
Also, free functions doing in-place modifications dont really make sense. They have been removed.
Here are the naming changes:
* `invert` -> `inv`
* `inverted` -> `Inv::inv_cpy`
* `transpose` -> `transpose`
* `transposed` -> `Transpose::transpose_cpy`
* `transform_by` -> `append_transformation`
* `transformed` -> `Transform::append_transformation_cpy`
* `rotate_by` -> `apppend_rotation`
* `rotated` -> `Rotation::append_rotation_cpy`
* `translate_by` -> `apppend_translation`
* `translate` -> `Translation::append_translation_cpy`
* `normalized` -> `Norm::normalize_cpy`
* `rotated_wrt_point` -> `RotationWithTranslation::append_rotation_wrt_point_cpy`
* `rotated_wrt_center` -> `RotationWithTranslation::append_rotation_wrt_center_cpy`
Note that using those static methods is very verbose, and using in-place methods require an
explicit import of the related trait.
This is a way to convince the user to use free functions most of the time.
Sébastien Crozet
Jan Niklas Hasse