[Development] Views

[Mutz, Marc]

On 2019-06-06 11:08, Simon Hausmann wrote:
> Am 06.06.19 um 10:42 schrieb Mutz, Marc via Development:
[...]
>> Do you guys _actually_ think that readability of Qt code trumps
>> _everything_?
> 
> 
> For me the answer is "no". I believe that for the majority of Qt code 
> we
> should strike for a compromise - as opposed to "trumping everything" -
> and certainly use more low-level code in areas that we know are
> particularly performance sensitive. That includes for example the
> software rasterize, the inside of QString or the text shaping.

These are areas where we need offensive _optimisation_, yes, I agree.

[...]
> Yes, we have an obligation to our users and we have an obligation to 
> the
> rest of the community that's developing Qt. I strongly suspect that you
> are in fact in agreement with me that the code that we have in code 
> must
> strike that compromise so that others in the project continue to feel
> comfortable to read, understand and modify the code and yet we can
> deliver a product to our users that's competitive in terms of
> performance (run-time, code size, etc.).

Indeed, we agree here.

> What we appear to disagree on is the exact line of complexity / style /
> noise.

To put it poignantly: We disagree on our judgement of the ability of Qt 
devs to learn the STL. I think they can, you think they can't.

> We also don't have to see eye to eye on this, I think. I think
> that simply leaves us with the established decision making process,
> where with our changes we have to appeal to the approvers in the 
> project
> and rely on the lazy concensus here. In the context of that, I note 
> your
> strong objection to Joerg's statement while I agree with Joerg.

As I note Lars' approval of the change from QVector to std::vector, even 
though it sprinkled int/size_t casts all over the place.

You appeal to the status quo. Replacing a QMap with a QHash for a 
five-entry data stucture is not a change, it's churn. I'd like to 
educate people in how to make simple data structures do what they need 
from them, without resorting to complex data stuctures. Does his appeal 
to reviewers? Probably less so. Is it necessary? Yes, I think so.

>> I have the feeling that some participants of these discussions thought
>> they joined an adulation club for Qt API lovers instead.
>> 
> 
> I don't quite understand what you're trying to say with adulation club
> for Qt API lovers. Could you explain this, please? Am I supposed to 
> feel
> insulted or offended?

You can mentally replace it with "fan club": Some people act as if Qt's 
API is superior to all other APIs. Well, it's not. It has weaknesses 
too, it's ugly, too (QGradientStop::first?!), and people should rise 
above this and see it for what it is: An API with a certain set of 
principles, not always honoured, also ageing sometimes. It's use should 
be justified the same was as the use of the STL is: what's better (for 
any sense of of the word). It's not bad just because it's not Qt.

Thanks,
Marc