From: "phluid61 (Matthew Kerwin)" <matthew@...>
Date: 2013-04-24T12:10:35+09:00
Subject: [ruby-core:54541] [ruby-trunk - Feature #8237] Logical method chaining via inferred receiver


Issue #8237 has been updated by phluid61 (Matthew Kerwin).


wardrop (Tom Wardrop) wrote:
> =begin
> The primary purpose of this proposal is to avoid unnecessary temporary variable assignment and extra expressions. This was good enough justification for the introduction of #tap, so perhaps it's a good enough reason to be considering this proposal. Which this in mind, perhaps the logic for this proposal should be changed. Perhaps, instead of the return value of the last expression being the inferred receiver, it may be more useful for the inferred receiver to correspond to the last object to be operated on, i.e the last method receiver. To re-use the method chaining example (which I'll remind is only one potential use case):
> 
>     user.nil? && !.profile.nil? && !.website.nil? && .thumbnail
> 
> This allows for potentially more use cases. For example, how often do you see patterns similar to the following?
> 
>     .to_s if my_symbol.is_a?(Symbol)
> 
> If you could reference this inferred receiver without invoking a method call, it could be even more useful. This would probably require a change to the implementation, so that instead of the receiver being implied, a special variable instead holds the last object to be operated on, such as the underscore. Here's another common pattern:
> 
>     return type if type =~ /^[a-z]/
>     # could be rewritten as...
>     return _ if type =~ /^[a-z]/
> 
> You may wonder what the benefit there is, but imagine something like this:
> 
>     return _ if self.options[:email][:server] == /localhost|127\.0\.0\.1/
> 
> I hope this demonstrates that there's potential for something to be done here.
> =end

I don't like the "last object to receive a method" idea.  For one you'd have to refine it to "the last object receive a method in the current scope", possibly with a "but not in the current expression" clause (depending on how a.b(_) is parsed); and clarify what is a method and what is not (e.g. & vs && ); and now there's so much mental baggage going along with it you lose a bunch of understandability to gain a little bit less typing.

And I particularly dislike those examples;  there's too much obscure syntax magic going on, it's hard to get a feel for the line at a glance.  With the if-modifier I'd really prefer the magic to come later *in lexical order*, e.g.:

  return self.options[:email][:server] if _ =~ /localhost|127\.0\.0\.1/

I have no idea how that would possibly be defined or implemented.

Since you brought up #tap, I'll note that that line could be represented almost as well (and without duplicated method calls) using:

  self.options[:email][:server].tap{|s| return s if s =~ /localhost|127\.0\.0\.1/ }

I find myself drifting more to the -1 side for this feature.


All that said, I quite like the idea of a magic variable that holds "the value of the last evaluated expression", in lexical order.  Rather than _ I'll use $% in some examples:

  # Rodrigo will hate this one, but I don't care:
  a && $%.b && $%.c && $%.d
  
  foo = 1
  bar = ->{ foo + 1 }
  baz = ->{ $% + 1 }
  foo = 99
  bar[] # => 100
  baz[] # => 2

However I'm not entirely convinced of its widespread usefulness.
----------------------------------------
Feature #8237: Logical method chaining via inferred receiver
https://bugs.ruby-lang.org/issues/8237#change-38854

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/