From: Trans <transfire@...>
Date: 2007-01-22T06:25:36+09:00
Subject: Re: Hash pairs at?


dblack@wobblini.net 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.

Avoiding net loss, how about going for gross gain. So how about "fixing
it" so there is both?

  select
  select_pair

And {meth}_pair could also work for assoc arrays too.

T.