[ruby-core:54103] Re: [ruby-trunk - Feature #8237] Logical method chaining via inferred receiver

Em 08-04-2013 10:07, Matthew Kerwin escreveu:
>
> On Apr 8, 2013 10:39 PM, "rosenfeld (Rodrigo Rosenfeld Rosas)" 
> <[e-mail] <mailto:[e-mail]>> 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.