Hi --

On Mon, 22 Jan 2007, Joel VanderWerf wrote:

> gga wrote:
>> dblack / wobblini.net wrote:
>> 
>>> It's not incorrect or buggy; that's the way Enumerable#find_all works.
>>> In addition to being Enumerables themselves, arrays serve as the
>>> common container for the results of lots of different Enumerables.
>>> 
>> 
>> Sorry, David, but I disagree.  It may not be buggy (as the bugginess is
>> properly documented :), but it is certainly incorrect.  Re-read my
>> post.
>> Hash.reject, which is also an Enumerable, DOES return a hash.
>> Hash.find_all which is algorithmically the same as Hash.reject but
>> without a negation, does not.
>> Someone forgot to override find_all in the Hash case, but did remember
>> to do it for Hash.reject.  Or, if you are of the belief that indeed
>> Enumerables should always return an array, Hash.reject was incorrectly
>> overridden when it shouldn't have been.
>
> This does look a bit odd...
>
> irb(main):001:0> h = {1=>3, 5=>7}
> => {5=>7, 1=>3}
> irb(main):002:0> h.reject {|k,v| k==1}
> => {5=>7}
> irb(main):003:0> h.select {|k,v| k==1}
> => [[1, 3]]

A bit.  The funny thing, though, is that it of course makes it
possible to do either -- so the irregularity actually provides a kind
of resilience.  The consistent version, should it ever come into
being, will shut the door on one of them.

I know that people don't want to do select { not } and so on... so
I can see that it's not really ideal.  But it's kind of fascinating
that "fixing" it, in either direction, would result in a net loss of
functionality.


David

-- 
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
    (See what readers are saying!  http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)