Well, you can also think of “on” + <event>, like in: onWindowClosed, onMouseClicked, onBytesReceived, … In the same analogy, you could have onErrorOccurred.
Seems very intuitive to me. It depends if you want to react to a state or to the event causing that state. Cheers, Kurt > On 11 Jun 2015, at 20:29, Alan Alpert <[email protected]> wrote: > > On Thu, Jun 11, 2015 at 7:11 AM, Hausmann Simon > <[email protected]> wrote: >> 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. > > I strongly advocate against replacing onError with onFailure. The > issue as I see it is a conflict between classic (perhaps BASIC > derived?) convention of handlers being "on" + <state noun> versus our > convention of "on" + <past tense verb>. Failure, Error (and success, > completion etc.) are all the old convention so it's not worth moving > from Error just to another word in the same convention that we're > trying to escape from. I also don't like to conceptually pin error to > failure, because in rare cases you can still have a partial success > despite an error condition. > > Since there is this other convention that uses "onError" a lot (at > least in XMLHttpRequest), I can see how a similar (but past tense) > word would be confusing to many developers. So now we're weighing the > cost of confusing both new and old developers just to make the > refactoring support work better. I'm no longer convinced it's > worthwhile, so I'm with Simon on that it's better to stick to error() > for now. At least for the QML exposed APIs. > >> If I break out the thesaurus, then we also have >> >> errorBefell > > If we want to sound fancy, we can use an obscure language and then it > can be shorter too: tokFeil . Also solves the problem of looking like > other APIs, as they limited themselves to English. > > -- > Alan Alpert > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
