> -----Original Message----- > From: Development <[email protected]> On Behalf Of > Thiago Macieira > > On Wednesday, 5 February 2020 09:41:58 PST Alexander Akulich wrote: > > On Wed, Feb 5, 2020 at 6:58 PM Thiago Macieira > > > > <[email protected]> wrote: > > > The correct signal for an error situation is errorOccurred, like in > > > QLocalSocket and QProcess. > > > > Actually both QLocalSocket and QAbstractSocket renamed the "error()" > > getter to keep using "error()" signal as opposed to many other Qt > > modules "errorOccurred()" signals. > > Which is the opposite of QProcess and violates the naming convention. Signals > are named after verbs in the past tense and properties & property getters are > simple nouns. So "error" is the getter, "errorOccurred" is the signal.
Either option solves the ambiguity. What's more important to our users - a consistent naming convention or an early warning/compile error when adopting Qt 6? Considering that our naming convention for error() signals is inconsistent anyway, I favour an approach that highlights API changes early. From an API user's perspective, the errorOccurred() signal changes little of the existing inconsistency (code completion solves most of this problem too) but sets my up for an ugly runtime error. A renamed getter solves my ambiguity issues and the compiler tells me straight away that there is a change. Therefore I'd vote to keep it as is (after Timur's recent change) -- Alex _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
