[QGIS-Developer] discuss: What's our development gameplan for 3.0 and above?

[Alessandro Pasotti]

On Sat, Nov 11, 2017 at 10:27 AM, Richard Duivenvoorde <rdmailings at duif.net>
wrote:

> On 11-11-17 01:03, Nyall Dawson wrote:
> > The "TLDW" for interested parties:
> > - Qt containers (qlist, qvector, qmap, etc) are unmaintained, They
> > won't be removed by upstream, but you shouldn't use them if you have a
> > choice
> > - QList is absolute rubbish and should never be used, unless you're
> > forced to by Qt API. It's likely to be killed in Qt 6 (becoming just
> > an alias for QVector)
>

Here are my (very subjective) reasons for choosing one or the other approach

WHY USING MAINLY/ONLY QT API
- Qt API is well documented with examples on http://doc.qt.io/qt-5/ and
using a single API instead of a mix it's a clear advantage (you don't have
to constantly ask yourself which API you need to use in a particular call)
- Qt API is simple and intuitive
- Qt API is more readable (camel case, no std:: etc.)
- Qt Containers are simple to use and cheap to copy (with caveats)
- QString has no real alternative for UTF8


WHY USING MAINLY/ONLY STL API
- Qt Containers are not for-range loop friendly (detach issues)
- Qt Containers are kind of deprecated
- STL is part of a standard, may lower barriers to entry for not-Qt devs


CONCLUSIONS
- I feel that the real motivation is to stay away from Qt containers, if it
wasn't for them we would not probably be here discussing in the first place
- I'd try as much as possible to avoid mixing two APIs: if we go for STL,
let's try to minimize Qt API usage or constraint it to certain domains (for
example: QStrings manipulation, dispatcher, GUI)
- no strong opinions here, but the greatest danger is to not decide: we'll
end up with a mixture of APIs and styles and code reviews will become
completely arbitrary, with people asked to switch API depending on who
reviews the code (and when the review is made)
- whatever we agree upon, it *must* be documented clearly in coding
guidelines

WHAT TO DO?

We have a few strong C++ coders in this community, I think that the best
way to proceed would be to let them articulate the different options that
we have and - if the don't agree - let the core devs vote on the proposals
they come out with.


Btw, thanks for binging up this discussion!

Cheers.

-- 
Alessandro Pasotti
w3:   www.itopen.it
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20171113/40651902/attachment-0001.html>