From: "henry.maddocks (Henry Maddocks)" Date: 2013-04-09T14:29:48+09:00 Subject: [ruby-core:54126] [ruby-trunk - Feature #8237] Logical method chaining via inferred receiver Issue #8237 has been updated by henry.maddocks (Henry Maddocks). I don't support this because inferred or implicit variables are a 'Perlism' that we should avoid. It makes programs difficult to understand and it is easy to add subtle bugs that are hard to track down. The sample usages are poor code and your proposal doesn't improve understanding. user && user.profile && user.profile.website && user.profile.website.thumbnail What is the intent of this line? Chaining methods this way should be discouraged, not encouraged. "some string".upcase #=> SOME STRING I saved you 6 characters. These two are buggy (obj.success_message || obj.error_message).tap do |message| puts message.upcase if message end And if they're both nil? catch :halt do throw :halt, "For reasons" end if .nil? log.info "Request was halted" response.body = "Sorry, but your request could not be completed" end Were we halted or not? The chance of someone innocently inserting an expression between the catch and the if and not noticing are very high. As the Avdi Grimm article link above concluded, writing better code is the solution. In Ruby, if your code is ugly then that means you're doing it wrong. ---------------------------------------- Feature #8237: Logical method chaining via inferred receiver https://bugs.ruby-lang.org/issues/8237#change-38377 Author: wardrop (Tom Wardrop) Status: Open Priority: Normal Assignee: Category: Target version: =begin This is a feature suggestion that was raised while discussing issue #8191. The feature suggestion is to introduce some form of logical method chaining to address this reasonably common pattern: user && user.profile && user.profile.website && user.profile.website.thumbnail It would be reasonably trivial to shorten this to: user && .profile && .website && .thumbnail The implementation I propose would be for Ruby to allow an inferred receiver; the dot prefix would be the syntax for this. The inferred receiver would resolve to the result of the last expression in the current scope. For illustrative purposes, the following would work under this proposal: "some string" puts .upcase #=> SOME STRING Another example: puts .upcase if obj.success_message || obj.error_message # Instead of... message = (obj.success_message || obj.error_message) puts message.upcase if message This can also potentially provide an alternative option in syntactically awkward scenario's, such as dealing with the return value of an if statement or a catch block, avoiding the need for temporary variable assignment: catch :halt do # Do something end if .nil? log.info "Request was halted" response.body = "Sorry, but your request could not be completed" end The logical chaining scenario is the main use case however. I just wanted to demonstrate how the proposed implementation could also be used in other creative ways. =end -- http://bugs.ruby-lang.org/