Den tors 6 feb. 2020 kl 20:36 skrev André Pönitz <apoen...@t-online.de>: > > On Thu, Feb 06, 2020 at 01:51:17PM +0000, Alex Blasche wrote: > > > > > -----Original Message----- From: Development > > > <development-boun...@qt-project.org> 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 > > > > > > > > <thiago.macie...@intel.com> 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? > > Consistent naming will be beneficial for a much longer time than any > short term incentive to adopt Qt 6.
I'm with André, please focus on getting it consistent. It's one of the things I think many love about Q - they can guess what name a function will have (even without auto-complete). If this is not done for Qt 6 (a major) release, then what should it be done? (Never?). The gotcha introduced can be advertised in the release announcement, I think that's enough. My 2 cents. Elvis > > Andre' > _______________________________________________ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development