Issue #8237 has been updated by headius (Charles Nutter).


I believe this has been suggested and rejected before. It's similar to Groovy's ?. operator, which only proceeds with calls if the LHS is non-null. That particular syntax is incompatible with Ruby since methods can end in ? but a different syntax could be considered.

In the end I believe it still leads to bad code. You're ignoring the fact that you have nulls/nils in your system, which just leads to their propagation even further.

What I could see is a syntax that behaves sort of like instance_eval but without a closure or instance_eval's other quirks. So this code:

object.{foo && bar && baz}

would treat the fcalls and vcalls (calls without a receiver) as calls against the original object, and would be compiled/parsed like:

object.foo && object.bar && object.baz

Note that the example above is basically just like an instance_eval block call without the instance_eval. It also has a sort of "glob" feel to it.
----------------------------------------
Feature #8237: Logical method chaining via inferred receiver
https://bugs.ruby-lang.org/issues/8237#change-38660

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/