[Development] Avoid overloading of 'error'

Thiago Macieira thiago.macieira at intel.com
Wed Jun 10 16:35:17 CEST 2015


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




More information about the Development mailing list