From: Rick DeNatale <rick.denatale@...>
Date: 2008-07-01T22:42:25+09:00
Subject: Re: Hash#select returns an array but Hash#reject returns a hash...

------=_Part_3864_17765444.1214919917932
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Tue, Jul 1, 2008 at 8:48 AM, David A. Black <dblack@rubypal.com> wrote:

> Hi --
>
>
> On Tue, 1 Jul 2008, Srijayanth Sridhar wrote:
>
>
>>> that will change in newer version of ruby, eg ruby1.9
>>>
>>> irb(main):015:0> RUBY_VERSION
>>> => "1.9.0"
>>> irb(main):016:0> a=Hash.new
>>> => {}
>>> irb(main):017:0> a[1]=2
>>> => 2
>>> irb(main):018:0> a[2]=2
>>> => 2
>>> irb(main):019:0> a[3]=4
>>> => 4
>>> irb(main):020:0> a.select { |key,value| value > 2 }
>>> => {3=>4}
>>> irb(main):021:0> a.reject { |key,value| value <= 2 }
>>> => {3=>4}
>>>
>>> kind regards -botp
>>>
>>>
>>>
>> Thanks.
>>
>> So this is just some sort of artefact/legacy code that never got changed?
>>
>
> You can actually make a case that select and reject are not exactly
> symmetrical operations. Imagine a line of people:
>
>
>    Joe John Joan David Jim Jenny Jeff Matz
>
> If I tell everyone in the line whose name does not begin with J to
> step backwards (reject), the original line is smaller but it's still
> the same line.
>
> If I tell everyone whose name *does* begin with J to step forwards
> (select), I've got a new line of J people.


I'm having a hard time making the connection between this analogy and the
methods.

In the first case one could say that we end up with two lines, the
'original' one and the line of rejects.

But first of all, x.reject leaves x alone so the original 'line' is
unchanged.

And why can't we see your select example exactly the same way, except with
the resultant line of 'selects' just closer to you.


> "Same line" and "new line" don't necessarily map to "same object" and
> "new object" in Ruby (since the post-reject hash is a different hash).
> But it suggests that there's a difference, arguably, between select
> and reject, in terms of the formal disturbance of the object, which in
> turn makes it easier to understand why select would return objects in
> a different container, while reject would leave the container in the
> same form but just contain fewer things.


Except that both select and reject leave the original container the same.
The analogy might be more apt for reject! and select! (if the latter method
existed).


>
> However, that doesn't mean it's bad for select to return a hash (which
> it does, as was mentioned, as of 1.9). Just that the behavior of one
> doesn't necessarily imply the behavior of the other.
>

The real change, it seems to me is that pre 1.9 the Ruby enumerator methods
had/have a preference for returning arrays rather than an instance of the
same class as the receiver, whereas 1.9 seems to be shifting to a preference
for returning an instance of the same class as the receiver where that makes
sense.

-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

------=_Part_3864_17765444.1214919917932--