David Alan Black wrote: > But you really do get into the problem that Eli Green mentioned, namely > that you're then storing all these things rather than iterating over them. > That could be very costly. Yes, but sometimes that is exactly what you were going to do anyways. It's not that storing them instead of iterating over them is preferable, but sometimes you have no choice. Given that, a statement like nums = list.eachOver57 makes intuitive sense, where eachOver57 is an iterator method. > Also, what do you mean by "return"? Methods still need to have a return > value. For example: > > def thing > yield 123 > return 456 > end > > In the absence of a block, what would happen to that 123? Well, alot of iterator methods are usually only called for their side-effects (with [1,2].each {...} we don't really care what each returns). So the way to approach this would seem to be to have an iterator method (which doesn't have to return anything else) return a call to yield, which would have to have a different behavior (all the things discussed, like the ability to detect when it was called without a block, and use a ?default? block instead). So one example of an iterator method where this would work would be: def someIterator yield 1, 2 return yield (3,4) end but it wouldn't work with: def otherIterator yield 1, 3 return 15 end However, many iterator methods already resemble the former. So the real challenge is to change the behavior of yield. Of course, for this to work yield would need to be able to have a default block to fall back on which is able to preserve the state of the Array to be returned between calls from yield. This would be a nice feature which I also can't see breaking alot of code (not that not breaking code should be a large impediment to improvement anyways). > > > def ytest > > > return 123 > > > end > > > > > > ytest do |x| print x end # prints 123 > > > > > > def ytest > > > yield(456) > > > return 123 > > > end > > > n = ytest do |x| print x end # prints 456 > > > print n # prints 123 The more I think about this the better it sounds. If I had to guess at a way to implement it I would say that Object could have a method which would place itself into an Array object and return a call to each like: class Object def c2i #for "coerce to iterator"? return [self].each end end Of course, Array and related classes would have to override c2i to get the an intuitive effect: class Array def c2i return each end end So the first ytest would have to be used like: ytest.c2i do |x| print x end # prints 123 But would it would be nice if c2i had more of an operator feel to it?