Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Results: simplify the Interface : ResultHandler #39

Open
chalkie666 opened this issue Aug 24, 2015 · 4 comments
Open

Results: simplify the Interface : ResultHandler #39

chalkie666 opened this issue Aug 24, 2015 · 4 comments

Comments

@chalkie666
Copy link
Collaborator

An idea from Dscho:
"Continue the (good!) idea of ResultHandler, but simplify it first.
eg: Why does every method in ResultHandler repeat that it handles something?"

I see what he means:
void handleWarning(Warning warning);
could just be
void warning(Warning warning);
but maybe that's too little information as method names should be verbs...

so maybe this one is just a matter of taste...
processWarning
dealWithWarning
showWarning
useWarning

or maybe I miss the point...?

@dscho
Copy link
Contributor

dscho commented Aug 24, 2015

void handleWarning(Warning warning);
could just be
void warning(Warning warning);
but maybe that's too little information as method names should be verbs...

warn()

@chalkie666
Copy link
Collaborator Author

And, to think,
I thought you might not be watching @dscho
!!!

Warn()
Certainly makes 100% sense!
But what about
handleResult()
?
Why is it so bad to have methods called handle in handler Interface? Does it go against some code style or logical way of thinking? Seems reasonable to me... But then again, I'm no object oriented design boffin.

@dscho
Copy link
Contributor

dscho commented Aug 31, 2015

I thought you might not be watching @dscho

lurking is the more appropriate word here... If I were actually active in this project, your concerns would all be addressed by now 😏

Why is it so bad to have methods called handle in handler Interface?

It is a bad habit to acquire. Repetition makes for bugs. Or even tyops. Guess how thrilled I am when I spend about 25% of my bug fix time on completing German-style names? Anyway, I'm going back to lurking mode.

@ctrueden
Copy link
Member

Code should be as easy to understand as possible, so that we can all contribute together. The biggest keys to that are consistency and conciseness. And in this situation, warn is clearly the best name along those lines.

@etadobson etadobson added this to the m1 milestone Oct 2, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants