From: "wardrop (Tom Wardrop)" <tom@...>
Date: 2013-04-09T11:04:19+09:00
Subject: [ruby-core:54122] [ruby-trunk - Feature #8237] Logical method chaining via inferred receiver


Issue #8237 has been updated by wardrop (Tom Wardrop).


=begin
@phluid61 In your example...

    "abc"
     foo = lambda { .upcase }
     "def"
     foo.call

I would imagine that to either produce an error along the lines of "could not infer receiver" or "inferred receivers must be preceded by a valid expression", or we believe it's logical to default the inferred receiver or nil, it'll produce a NoMethodError.

Perhaps the inferred receiver should behave as if it was assigned to a variable, e.g.

     last_expression = "abc"
     last_expression = foo = lambda { last_expression = last_expression.upcase }
     last_expression = "def"
     last_expression = foo.call

I'd prefer it to be scoped though, so anywhere a local variable can be redefined, last_expression should be essentially reset. Something like this...

    last_expression = "abc"
    last_expression = foo = lambda do
        last_expression = nil
        last_expression = last_expression.upcase
    end
    last_expression = "def"
    last_expression = foo.call

I think I'd prefer it to behave like that, but instead of defaulting to ((|nil|)), have it default to some special internal value that indicates that the last expression hasn't be set, and to raise an appropriate error if it's used.

I'm not sure how difficult this would be to implement from a performance perspective though. I imagine it would be expensive to assign the result of every expression to a variable, so hopefully it could be optimised in a way that it's only stored when an inferred receiver is used in the next expression.

@rosenfield I believe what you're after is different to this request. This is about an extension to a particular pattern involving logical AND, as well as proposing an implementation that has other practical applications. The behaviour you want would result in a completely different proposal that solves a similar but logically different problem. Feel free to raise such a proposal as a feature request and link to it; I'd just like to keep that discussion somewhat independent of this one. The two proposal's can then be more easily compared if they overlap.
=end
----------------------------------------
Feature #8237: Logical method chaining via inferred receiver
https://bugs.ruby-lang.org/issues/8237#change-38374

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/