socketry / async-container

Scalable multi-thread multi-process containers for Ruby.
MIT License
81 stars 4 forks source link

Examples: implicit return, avoid unused variable #10

Closed olleolleolle closed 4 years ago

olleolleolle commented 4 years ago

This PR updates examples to avoid a -W2 warnings (about an unused variable).

coveralls commented 4 years ago

Coverage Status

Coverage remained the same at 79.173% when pulling 966c4f7d7619f05895fd5a0fae3e06dc310e4869 on olleolleolle:avoid-verbose-ruby-warning-in-example into 45a2f5dab80e21647a14bc79cf1ce869f5f42ebe on socketry:master.

ioquatix commented 4 years ago

I like this, but I'm also on the fence. What's your internal model for implicit returns?

For me, I see implicit returns as part of a functional style. As soon as I feel there is any ambiguity as to what is going on, I try to use explicit returns. The reason for that is because I've seen implicit returns cause bugs, especially as ruby is dynamically typed and the interpreter can't generally warn you if something implicit becomes part of the public interface (or something that was implicit is no longer, due to changes in flow control).

Welcome any thoughts.

olleolleolle commented 4 years ago

The model for me would be: everything has a return value and if I want it to be nil in some cases ("oh the exception I handled by logging it returns the Logger instance instead of acting like puts which returns nil") I need to make it nil there.

In YARD, there's a return type called void, which is used to communicate to a reader that whatever is returned here is... To be unused. I find that a TODO in the implementation, I'd want people implementing to decide if that actually returns anything.

Thanks for asking, I perhaps had a folk model of this, and it helped me to express it.