Hi, I agree about the inconsistency in tense, that is a good argument against error(), although it is similarly unfortunate that the inconsistency in tense is more widespread than assumed.
I'm not sure onErred or onErrored is any better, to be honest. I think it's more likely to result in a typo than the most basic form of the word - error - instead of some conjugation. In the light of that I think I'd prefer onFailed or onFailure - but I think it would perhaps be a mistake to make our existing APIs more inconsistent than necessary. It seems like an unfortunate choice, but I think it's better to stick to error() than to have some QML types have onError and some have onFailure. Simon ________________________________________ From: Alan Alpert <[email protected]> Sent: Wednesday, June 10, 2015 18:59 To: Hausmann Simon Cc: Thiago Macieira; [email protected] Subject: Re: [Development] Avoid overloading of 'error' On Wed, Jun 10, 2015 at 8:14 AM, Hausmann Simon <[email protected]> wrote: > 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:... I disagree that it looks good in QML as onError, almost all other signal handlers are past tense so it is visibly odd. But it's nice to be so short, so maybe a direct past-tense-ify of "onErrored"? If you don't like using error as a verb, we can use a similar (yet shorter) verb: "onErred". Not that I really mind the exact name of the new signal. -- Alan Alpert _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
