Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Not a rubyist, but I love that collect() made it into Rust, too. I feel like it takes the role that generators have in Python, but is much easier to reason about in terms of the control flow and what data is being passed where.


Enumerable#collect is just an eager version Python map() in method rather than function form (#map is a avaulable as an alias for #collect); it is a little more concise for when the function you are mapping over is a method on the object being processed (even more than Ruby’s normal advantage with lambdas), but not fundamentally more powerful.

(Enumerable#lazy gives you an object where collect/map is, and other merhods are, lazy rather than eager.)

> I feel like it takes the role that generators have in Python

Ruby has generators, though in either Ruby or Python map/collect (the lazy versions, in Ruby) can be used for some of their uses, since it basically produces a generator from an input collection or generator and a mapping function.


#collect is an alias for #reduce, not #map, making it like Python reduce().


> #collect is an alias for #reduce

It’s not, though. (If it was, we could write about its equivalence with Python’s [from functools in py3, core in Py2] reduce function, though, saying much the same thing as about the actual equivalence with map upthread, except reduce/inject is less often a substitute for generators than map/collect.)

#map is an alias for #collect. [0]

#reduce has the alias #inject. [1]

[0] https://ruby-doc.org/core-3.0.2/Enumerable.html#method-i-col...

[1] https://ruby-doc.org/core-3.0.2/Enumerable.html#method-i-inj...


Then should the example in the above comment, `some_enum.collect(&:+)`, be using reduce instead of collect?


Yes. My bad. :)

I haven't been a professional Rubyist in some years but my habit here was to use inject.


You’re right. My apologies.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: