From: Rodrigo Rosenfeld Rosas Date: 2013-04-08T22:22:00+09:00 Subject: [ruby-core:54103] Re: [ruby-trunk - Feature #8237] Logical method chaining via inferred receiver This is a multi-part message in MIME format. --------------080803040401030503030604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Em 08-04-2013 10:07, Matthew Kerwin escreveu: > > On Apr 8, 2013 10:39 PM, "rosenfeld (Rodrigo Rosenfeld Rosas)" > > wrote: > > > > I really believe it would be better to isolate each wanted feature > in a separate ticket instead of mixing several ideas in the same > ticket. Also, I guess you should state clearly that a&&.b&&.c should > mean (tmp1 = a; tmp1 && (tmp2 = tmp1.b); tmp2 && tmp2.c), meaning that > each method should be evaluated just once in the chain. > > > > Anyway, I'm -1 for this proposal (with the implementation above) > because it doesn't make any sense to me to call any method on the > "false" object in most real-world codes out there. I'm favorable to > adding a shortcut syntax for chaining methods, but I believe it should > check for "nil?" only. I don't have an opinion yet if it should abort > the entire statement if a subexpression is nil, like CoffeeScript > does, or simply replace the subexpression with "nil" and let the > expression go on with the evaluation, like Groovy does. > > I think you've missed the point of this request. There is only one > wanted feature, and it has nothing to do with "checking for nil", > except that it can be used to simplify a common pattern already > employed for that purpose. > > Note that this one also theoretically allows such constructs as: > > foo[bar] || .inspect > baz if .empty? > I didn't miss the point, I'm simply -1 for it. I see the case for chain-able calls and I do use it sometimes when coding in Groovy and CoffeeScript. But I can't find this proposal will lead to more readable code and I'm unsure what problem exactly it is trying to solve. > or > > "41" << .to_i(16).chr #=> "41A" > > Strange examples, but possible nonetheless. > Exactly. If you could present us more concrete examples, maybe you could change my mind. --------------080803040401030503030604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Em 08-04-2013 10:07, Matthew Kerwin escreveu:

On Apr 8, 2013 10:39 PM, "rosenfeld (Rodrigo Rosenfeld Rosas)" <rr.rosas@gmail.com> wrote:
>
> I really believe it would be better to isolate each wanted feature in a separate ticket instead of mixing several ideas in the same ticket. Also, I guess you should state clearly that a&&.b&&.c should mean (tmp1 = a; tmp1 && (tmp2 = tmp1.b); tmp2 && tmp2.c), meaning that each method should be evaluated just once in the chain.
>
> Anyway, I'm -1 for this proposal (with the implementation above) because it doesn't make any sense to me to call any method on the "false" object in most real-world codes out there. I'm favorable to adding a shortcut syntax for chaining methods, but I believe it should check for "nil?" only. I don't have an opinion yet if it should abort the entire statement if a subexpression is nil, like CoffeeScript does, or simply replace the subexpression with "nil" and let the expression go on with the evaluation, like Groovy does.

I think you've missed the point of this request. There is only one wanted feature, and it has nothing to do with "checking for nil", except that it can be used to simplify a common pattern already employed for that purpose.

Note that this one also theoretically allows such constructs as:

foo[bar] || .inspect
baz if .empty?

I didn't miss the point, I'm simply -1 for it. I see the case for chain-able calls and I do use it sometimes when coding in Groovy and CoffeeScript. But I can't find this proposal will lead to more readable code and I'm unsure what problem exactly it is trying to solve.

or

"41" << .to_i(16).chr #=> "41A"

Strange examples, but possible nonetheless.

Exactly. If you could present us more concrete examples, maybe you could change my mind.
--------------080803040401030503030604--