Re:Ruby's Creed
by pmontra on Wednesday April 03, 2019 @03:28AM
(#19561477)
They both look ugly to me. Furthermore, there is a cognitive burden.
There is nothing to think about in
I even use to write it more explicitly as
The short forms
are like "oh wow, what does that mean?" and I've been using Ruby since 2005. And the ugliness...
[ Parent
| on HN ]
Re:Ruby's Creed
by irishsultan on Wednesday April 03, 2019 @09:05AM
(#19562948)
It's not
users.map{&:name}
but users.map(&:name)
The &something syntax to pass on a block is very old syntax to allow passing on a block that is reified as a Proc, it mirrors the syntax used to receive a block (if you don't want to use, or can't use yield, for example because you need to pass on the block to another method).e.g.
def apply_to_all(&callback)
@all.each(&callback)
end
or def initialize(a, b, c, &block)
@a = a
super(b, c, &block)
end
The only thing that &:symbol adds is that it defines to_proc on Symbols to create a Proc object that sends the symbol to it's first parameter, you could define it yourself if Ruby didn't already, and in fact it was first defined by users of Ruby before it became part of Ruby core.Definition:
class Symbol
def to_proc
return Proc.new {|receiver| receiver.send(self)}
end
end
This definition allows `["1", "2", 3].map(&:to_i)` to work in Ruby 1.8.6, which otherwise doesn't support it.Thanks. As you see I dislike that syntax so much that I never learned how to write it. It's not something I'll actively use.
Re:Ruby's Creed
by ben-schaaf on Wednesday April 03, 2019 @04:21AM
(#19561711)
I don't actually mind the syntax that much, `&` on a symbol just gives you a proc for calling `send` on the first argument. What bothers me is the limitations. If you're going to have special case syntax to avoid having a useless first argument why not go all the way?
Something like this would have made a lot more sense imo:
users.map { .name.uppercase + '3' }
numbers.map { * 3 }The last one looks a lot like Haskell:
map (* 3) numbers
Re:Ruby's Creed
by irishsultan on Wednesday April 03, 2019 @09:06AM
(#19562958)
The reason for the limitation is that it was existing syntax, with a different purpose (see the sibling post to yours).
The cognitive burden argument is completely subjective. If you’re used to point-free programming, the first short form probably requires less cognitive burden. To me, it makes way more sense to think about “map the users list over the function that returns name” rather than “map the users list over a brand new anaonymous function that takes a user and calls the name method on it.”