[Development] Avoid overloading of 'error'

Samuel Gaist samuel.gaist at edeltech.ch
Wed Jun 10 16:36:42 CEST 2015


On 10 juin 2015, at 16:20, Koehne Kai <Kai.Koehne at theqtcompany.com> 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?
> 
> Regards
> 
> Kai
> 
> --------
> Kai Köhne, Senior Software Engineer - The Qt Company GmbH
> 
> The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
> Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
> 
> 
> 

Hi,

I agree that signal and accessor of the same name should be avoided.

What about errorOccured ? 

failed doesn't always mean there was an error with a direct relation.

Regards

Samuel


More information about the Development mailing list