[Development] Avoid overloading of 'error'

Hausmann Simon Simon.Hausmann at theqtcompany.com
Wed Jun 10 17:14:07 CEST 2015


Hi,

I think renaming the getter to lastError is nice! I however do like error as signal name and it looks good in qml as onError:...


Simon

  Original Message
From: Thiago Macieira
Sent: Wednesday, June 10, 2015 16:35
To: development at qt-project.org
Subject: Re: [Development] Avoid overloading of 'error'


On Wednesday 10 June 2015 14:20:51 Koehne Kai wrote:
> Hi,
>
> I'm currently converting a codebase from old-style connects to new-style
> ones. Thanks to Qt Creator's refactoring support this is actually quite
> easy ... it gets ugly though when either the signal or slot method name is
> overloaded, and you have to write nice code like
>
>       connect(&process, static_cast<void
> (QProcess::*)(QProcess::ProcessError)>(&QProcess::Error), this,
> &MyClass::processError);
>
> There can be done little to avoid this in general, but actually the
> overloading of 'error' stands out: E.g. QProcess, QNetworkReply,
> QNetworkSession, QAbstractSocket all feature both an error() signal and an
> error() accessor.
>
> Ideas how to mitigate this:
>
> 1. We could deprecate the error() signal, and add a failed() signal (still
> in Qt 5).
> 2. We could rename error() accessor to lastError() in Qt 6.
> 3. <your idea goes here>
>
> Comments?

I like both 1 and 2.

"error" isn't a verb in the past, so it's a bad name for a signal. "failed" or
another construct with a verb in the past is better. Even "errorEncountered"
would be fine.

Changing "error" to "lastError" for the getter also makes sense, since it
clearly indicates that it's the last error that happened. If no error
happened, then this function may or may not return anything intetersting. But
if you rename that function, you should also rename errorString to
lastErrorString.

So I recommend we begin the shift now in 5.6 and deprecate the old methods, to
be removed in 6.0.

As for the implementation, please connect one signal to the other, so we don't
need to duplicate the emissions. But note that there will be an delivery order
problem: all slots connected to one signal will be received before all slots
connected to the other. Unless Olivier adds a signal alias feature to moc :-)

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development



More information about the Development mailing list