On Tue, Nov 10, 2009 at 10:47 AM, Brian C. [email protected]
wrote:
other Enumerators. When you want a real array, then add .to_a to the
end.
And you base this ultimate conclusion on what?
Prior to Ruby 1.9, most Enumerable methods required that a block be
passed and would raise an error if not. There are few, such as to_a
which did not.
If you wanted an enumerator you needed to do something like
(1…100).enum_for(:inject, 0)
In Ruby 1.9 the enumerable methods got a little more relaxed, they
work as before if a block IS given, and if not they return an
enumerator instead.
So, my ultimate conclusion is that enumerable methods should almost
always use a block passed as an argument to do whatever they do, and
for Ruby 1.9 at least return an enumerator if a block is not passed
which will do whatever the enumerable itself would do with a block.
And a Ruby method can’t distinguish wheter it was called with syntax
like
some_method { # some block
}
or
some_method(&something_which_understands_to_proc)
In both cases block_given? inside the method invocation will return
true.
Now as I understand it, the proposal would be to make
list.map(:method)
do the same thing as
list.map(&:method)
One problem with this is what to do with something like
list.inject(:initial_value)
Where instead of a proc, :initial_value represents the initial value
for an enumerator. I would argue that only the caller knows which one
he/she wants.
That “&” is pretty important in distinguishing these two cases.
–
Rick DeNatale
Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale