Re: [boost] [qvm] Terseness of syntax etc.

Subject: Re: [boost] [qvm] Terseness of syntax etc.
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-12-10 01:48:36

Le 10/12/2015 00:58, Emil Dotchevski a écrit :
> On Wed, Dec 9, 2015 at 3:41 PM, Vicente J. Botet Escriba <
> vicente.botet_at_[hidden]> wrote:
>
>> Le 09/12/2015 13:43, Agustín K-ballo Bergé a écrit :
>>
>>> On 12/8/2015 1:25 PM, Phil Endecott wrote:
>>>
>>>> Adam Wulkiewicz wrote:
>>>>
>>>>> The formal review of Emil Dotchevski's QVM library begins today on 7th
>>>>> Dec and ends on 16th Dec.
>>>>> Full documentation is also viewable on Github:
>>>>> http://zajo.github.io/boost-qvm/
>>>>>
>>>> I find most of the identifiers too short.  To give just a couple
>>>> of examples: "transp" is used to mean "transpose".  You save
>>>> typing three letters, and get confusion with transparent,
>>>> transport, etc.  Then look at the names of some traits classes;
>>>> elsewhere we have type_traits, allocator_traits, iterator_traits
>>>> etc. all spelt out in full, but in qvm we have q_traits, v_traits
>>>> and m_traits.  I could go on but really almost every identifier
>>>> is too short for my tastes.
>>>>
>>> I used an earlier version of the library several years ago, back when it
>>> was called "Boost.LA", and I found extremely short identifiers to be a
>>> concern too. I could understand going for `mat` and `vec` instead of
>>> `matrix` and `vector`, but not just `m` and `v`. For pretty much every
>>> other identifier, I would like to see a full blown word instead.
>>>
>> I'm not sure we need the prefix nor the suffix. The operations shouldn't
>> have the type on its name.
>> If the operation depends on a concept (vector, matrix, quaternion) and the
>> operation has no parameter of this type the function should have the type
>> as parameter
>>
>> What would be wrong replacing
>>
>>      float vmag = mag(v);
>>      float33 m = rotx_m<3>(3.14159f);
>>      vref(v,YXZ) = rotx_m<3>(3.14159f) * v;
>>
>> by
>>
>>      int mag = magnitude(v);
>>      float33 m = rotate_x<M3>(3.14159f);
>>      ref(v).YXZ() = rotate_x<M3>(3.14159f) * v;
>>
> Let me point out first that in this library q always means quaternion, m
> always means matrix, and v always means vector. With that in mind, could
> rotx_m<3> be misinterpreted?
>
> Secondly, the semantics of rotx_m are different from what you're imagining.
> It does *not* return a "proper" matrix object, it returns a reference to
> its argument reinterpreted as an unspecified non-copyable 3x3 matrix type,
> which essentially allows the passed angle (3.14159f) to participate as a
> 3x3 matrix in QVM operations without creating a temp. That's why when
> instantiating the rotx_m template you specify the dimensions but not the
> type of the matrix (of course you can assign the result to any compatible
> matrix type.)
>
> I'm really not a fan of the old operator% and now operator, syntax.
>>>> To me, (v,XY) looks like you're forming a row-vector with two elements.
>>>> Is there a reason why these accessors can't be written with function
>>>> syntax, i.e. XY(v) ?  Or, for matrices, something like element<4,2>(m)
>>>> rather than (m,A<4,2>) ?
>>>>
>>> The precedence issues are so bad with `operator,` that one has to pretty
>>> much always wrap it in parens, that makes all precedence issues go away. I
>>> think for that reason it's a better choice than `operator%`, that mostly
>>> just works and bit me over and over again. There are reasons against it
>>> too, for instance a missing include, a typo, a shadowing variable will turn
>>> a swizzling expression into a regular comma expression.
>>>
>>> That said, if I have to write `(v,XY)` instead of `v.XY` I'd rather write
>>> `XY(v)` instead.
>>>
>>>
>> Clearly the operator, is too controversial.
>>
>> Isn't
>>
>>      qvm::ref(v).XY()
>>
>> terse enough?
>>
> Compared to (v,XY)?
>
>
The best is the enemy of the good.

I requested if it is not terse enough.

Vicente