|
Boost : |
Subject: Re: [boost] [qvm] Terseness of syntax etc.
From: Francois Duranleau (xiao.bai.xiong_at_[hidden])
Date: 2015-12-09 07:58:54
On Wed, Dec 9, 2015 at 7:43 AM, AgustÃn K-ballo Bergé
<kaballo86_at_[hidden]> wrote:
> On 12/8/2015 1:25 PM, Phil Endecott wrote:
>>
>> 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 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.
>
>> I'll be interested to see what others think about these and other
>> aspects of the proposal.
+1 to all of the above.
-- François
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk