From: dblack@...
Date: 2007-06-22T00:12:04+09:00
Subject: Re: Behaviour of Enumerables reject vs. select mixed into Hash

Hi --

On Thu, 21 Jun 2007, Yossef Mendelssohn wrote:

>
> On Jun 21, 5:37 am, dbl...@wobblini.net wrote:
>> Yes, but making a special case of Hash, as opposed to other
>> enumerables, is exactly what breaks duck typing.  I would actually
>> prefer to see Hash#reject return an array.
>>
>> I like having arrays be the "common currency" of select operations.  I
>> don't think there's anything that you're prevented from doing as long
>> as that's the case.
>>
>> David
>
> The inconsistency of return values between Hash#reject vs. Hash#select
> has bothered me for a long time.  Above all, I'd want this to be
> consistent, but unlike you (and I believe like the majority), I'd like
> both to return a Hash.
>
> I'm not really sure how duck typing even enters into it as a serious
> concern.  The blocks given to reject/select are different based on the
> Enumerable type.  Consider:
>
> irb(main):017:0> %w{red green blue}.select { |elem|  elem.length > 4 }
> => ["green"]
> irb(main):018:0> {:red => true, :green => true, :blue => true}.select
> { |elem|  elem.length > 4 }
> (irb):18: warning: multiple values for a block parameter (2 for 1)
>        from (irb):18
> (irb):18: warning: multiple values for a block parameter (2 for 1)
>        from (irb):18
> (irb):18: warning: multiple values for a block parameter (2 for 1)
>        from (irb):18
> => []
>
> I get an Array from both, which is wonderful if I'm expecting an Array
> and I want to flatten the return value or do any other Array-specific
> things.  The only problem is one array is useless and wrong.

Didn't you like my evasive use of "&select_block"? :-)


David

-- 
* Books:
   RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242)
   RUBY FOR RAILS (http://www.manning.com/black)
* Ruby/Rails training
     & consulting:  Ruby Power and Light, LLC (http://www.rubypal.com)