On Wed, Jul 23, 2003 at 09:04:20PM +0900, Robert Klemme wrote: > > I tend to dislike #inject cause it's almost always more complex than > > using #each + the needed logic (and slower too), > > I could agree with the performance issue, although I'd like to test that. > But I don't see the difference in complexity between: > > m = [] > enum.each{ |x| m << (m[-1]||0) + x } > > and > > m = enum.inject([]) {|m,x| m << (m[-1]||0) + x} The former is more readable for me. Possibly because I don't use inject often so it's not natural for me. And then again, why use the second if it's going to be slower and (at least for me) it's not clearer? > In fact, the formula is pretty much the same. :-) > > as it's providing the > > wrong sort of abstraction in many cases (gets further away from the > > problem domain, not closer, IMHO). > > Hm, that I don't understand. IMHO this follows the spirit of Ruby since > it allows to implement a lot of useful things very easily. Could you > elaborate or do you have any sources to back that up? #inject does two things: 1. pass elements sequentially to the block 2. propagate the state in many cases, (2) feels strange because I don't want the state object to be passed again and again to the block. In the previous example, I want to obtain the array corresponding to the integral; in my mind, it should be easy to track what 'm' is pointing to. But w/ inject, I have to make the effort to evaluate what 'm' represents in each iteration; admittedly not a really hard issue here, but even if it's only a bit more complex (in matz' terms: adds a little stress, consumes some brain power), #inject didn't buy me anything in that (and several other) examples. -- _ _ | |__ __ _| |_ ___ _ __ ___ __ _ _ __ | '_ \ / _` | __/ __| '_ ` _ \ / _` | '_ \ | |_) | (_| | |_\__ \ | | | | | (_| | | | | |_.__/ \__,_|\__|___/_| |_| |_|\__,_|_| |_| Running Debian GNU/Linux Sid (unstable) batsman dot geo at yahoo dot com Yes I have a Machintosh, please don't scream at me. -- Larry Blumette on linux-kernel