On Mon, 22 Jan 2007 05:58:25 +0900, dblack wrote:

> 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.

No it wouldn't because you could just call .to_a on the returned hash to
get the nested array representation.

--Ken

-- 
Ken Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.
http://www.iit.edu/~kbloom1/