Squeak
  links to this page:    
View this PageEdit this Page (locked)Uploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
inject:into:
Last updated at 4:34 pm UTC on 14 January 2006
Alexandre Bergel I am wondering why the binaryBlock passed to an 'inject:into:' do not bound the current element to the first argument. In some other words why do we write:
 #(a b c) inject: '' into: [:partialAnswer :el| partialAnswer , el] 
and not:
 #(a b c) inject: '' into: [:el :partialAnswer| partialAnswer , el]
It would more make sense, at least for me.

Samuel Tardieu Not to me. Your data will be handled from first to last, which is left to right in our current representation. It makes more sense to me to have an operator whose first argument is placed left (partialAnswer) and the second is placed right (el).
Bert Freudenberg I think it was Dan explaining the "graphical" metaphor for remembering the order of arguments: Imagine the blocks are chained from left to right. The initial value enters at the left, the next element is fed
from above, and each block's value leaves at the right going into the next block. The final value emerges on the right. So because the partial answer enters at the left it obviously is the first argument.
Travis Griggs If you view inject:into: as a general purpose accumulator, then the current order make some sense. I have shortcut'ed this method with a wrapper called accumulate: anAccumulation using: aBlock before. Then
the classical example:
 (1 to: 5) accumulate: 0 using: [:accum :each | accum + each]
or canonically
(1 to: 5) inject: 0 into: [:accum :each | accum + each]
makes more sense. That said... with the addition of fold: into VW, I have not used inject:into: in a long while now. fold: is even better for the classical example:
(1 to: 5) fold: [:a :b | a + b]
Not only is it terser, but is technically more scalable? Why?