Standardize on reduce vs inject

[myronmarston]

The rspec code bases are inconsistent here and it would be good to standardize. Quoting the earlier conversation from #1108:

@dchelimsky:

Small matter, but I much prefer reduce over inject since that's what other languages call it.

@myronmarston:

That makes sense, especially given you've been doing Clojure (which I presume calls it reduce).

I have a slight preference for inject, but for no valid reason: it's simply what I'm used to using, and it's what I generally see in code written by other rubyists. My instinct is to leave it as is, given that other projects I work on (especially at work) have settled on inject (so it helps with context shifting to keep this) but I don't care much.

@dchelimsky:

I've actually been thinking of combing through all the libs to do pull requests to change inject to reduce :)

I think it should be consistent within each lib, so if you really prefer inject, I'd recommend changing any reduces to injects. Or the other way 'round. WDYT?

@myronmarston:

What do others prefer? @alindeman @xaviershay @JonRowe @samphippen @soulcutter ?

(I'm happy to go with whatever the consensus is).

@dchelimsky:

This may help your evaluation: http://en.wikipedia.org/wiki/Reduce_(higher-order_function)

Looks like most languages call it fold, or the more specific foldl and foldr. reduce, or some variant, is the 2nd most common, used in in Lisp (and variants like Clojure) and Perl, Python, Javascript, etc. The only other languages that use inject are Smalltalk and Groovy.

@JonRowe:

I prefer inject, it's just been the way I've always thought of it but I'm ok with reduce...

[myronmarston]

I remembered one other reason I tend to prefer inject...

For a long time, I would forget the ordering of the yielded arguments, especially given that the ordering of the yielded arguments of each_with_object (which is quite similar) is the reverse. Then I realized that the names of the two methods reveal the ordering of the arguments:

• array.each_with_object({}) { |element, hash| }: Like each_with_index, this adds an additional yielded argument after the individual yielded element. It would be odd for the accumulator object to come first.
• array.inject({}) { |hash, element| }: I read this as "inject this hash into this array". The accumulator comes first because the method name is phrased to focus on what's being injected.

Since thinking that through, I've never again had a problem with the block arg ordering of these two. I don't think reduce suggests the argument ordering in the same way.

[xaviershay]

We should paint it green.

[xaviershay]

reduce, from http://xaviershay.com/ruby-style-guide#enumeration

It's an arbitrary choice for me though.

[JonRowe]

Using your own style guide to reinforce the argument, tsk, ;)

[xaviershay]

no point making a style guide if you don't get to refer to it

[fables-tales]

I'm up for reduce, which comes both from other languages and having
recently been prototyping a map-reduce framework in ruby at work (although
weirdly it's actually coreduce we're implementing (monads :))

Sent from my phone please excuse my brevity.

On 14 Oct 2013, at 05:47, Xavier Shay notifications@github.com wrote:

no point making a style guide if you don't get to refer to it

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/1110#issuecomment-26235491
.

[soulcutter]

Paint it blue! To me it's arbitrary. I wouldn't personally give PR feedback that it should be one way or another, I don't think there's any win in standardizing it or changing what's there.

Bradley Schaefer

On Oct 14, 2013, at 3:13 AM, Sam Phippen notifications@github.com wrote:

I'm up for reduce, which comes both from other languages and having
recently been prototyping a map-reduce framework in ruby at work (although
weirdly it's actually coreduce we're implementing (monads :))

Sent from my phone please excuse my brevity.

On 14 Oct 2013, at 05:47, Xavier Shay notifications@github.com wrote:

no point making a style guide if you don't get to refer to it

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/1110#issuecomment-26235491
.
—
Reply to this email directly or view it on GitHub.