2 ms·
On a team, I would prefer the former over the latter. As a single contributor that's trying to hack together an idea, the second option is not so bad; however,
by rajangdavis 8y ago
On a team, I would prefer the former over the latter.
As a single contributor that's trying to hack together an idea, the second option is not so bad; however, it will probably need to be changed far off in the future.
I think named block parameters are cool in the sense that they enable some expressiveness but bad in the sense that they lose some readability. I won't know how I truly feel until I have to maintain/read a large codebase where they are used.
- philwelch 8y agoHow do you feel about the Groovy/Kotlin style that would translate (roughly speaking): [1,2,3].map{|n| n * 2} to: [1,2,3].map{it * 2} ? It's not generalizable to multi-argument lambdas, but multi-argument lambdas are the ones that are more important to name. (e.g. with reduce, {|memo, it| memo += it})
- rajangdavis 8y agoI don't feel strongly one way or the other to be honest. It looks nice but it's not a syntax that I have been wanting or needing. If it enables people to express themselves better through code, then I'm all for it. I think as far as Ruby goes, I don't like the idea of introducing a new abstraction for something that already has a solution; however, I wouldn't villify someone for using it unless they wrote something that took a large number of arguments.
- vorg 8y agoThe underscore is fairly pleasant to read: [1,2,3].map{_*2} I think that's what Scala has. For multi-args, perhaps: [1,2,3].reduce{_1+=_2}
- vidarh 8y agoUnderscore is very commonly used to signifiy "I don't care about this argument" in Ruby, so at least on it's own it'd be confusing, and _1 is a valid local variable name, so would risk breaking existing code, though I've personally not seen it used, so maybe it'd be an acceptable risk.
- kazinator 8y ago(lambda (a b) (/ a b)) is not "a large code base".