Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > Hash#select returns an array but Hash#reject returns a hash...

Reply
Thread Tools

Hash#select returns an array but Hash#reject returns a hash...

 
 
Srijayanth Sridhar
Guest
Posts: n/a
 
      07-01-2008
Hello,

Is there any design reason for select returning an array and reject
returning a hash? Why this disparity?

Thank you,

Jayanth

 
Reply With Quote
 
 
 
 
Dave Bass
Guest
Posts: n/a
 
      07-01-2008
Srijayanth Sridhar wrote:
> Is there any design reason for select returning an array and reject
> returning a hash? Why this disparity?


In module Enumerable, both select and reject return an array (according
to the Pickaxe).
--
Posted via http://www.ruby-forum.com/.

 
Reply With Quote
 
 
 
 
Srijayanth Sridhar
Guest
Posts: n/a
 
      07-01-2008
irb(main):001:0> a=Hash.new
=> {}
irb(main):002:0> a[1]=2
=> 2
irb(main):003:0> a[2]=2
=> 2
irb(main):004:0> a[3]=4
=> 4
irb(main):005:0> a.select { |key,value| value > 2 }
=> [[3, 4]]
irb(main):006:0> a.reject { |key,value| value <= 2 }
=> {3=>4}


On Tue, Jul 1, 2008 at 4:09 PM, Dave Bass <(E-Mail Removed)> wrote:
> Srijayanth Sridhar wrote:
>> Is there any design reason for select returning an array and reject
>> returning a hash? Why this disparity?

>
> In module Enumerable, both select and reject return an array (according
> to the Pickaxe).
> --
> Posted via http://www.ruby-forum.com/.
>
>


 
Reply With Quote
 
Peņa, Botp
Guest
Posts: n/a
 
      07-01-2008
From: Srijayanth Sridhar [(E-Mail Removed)]=20
# irb(main):001:0> a=3DHash.new
# =3D> {}
# irb(main):002:0> a[1]=3D2
# =3D> 2
# irb(main):003:0> a[2]=3D2
# =3D> 2
# irb(main):004:0> a[3]=3D4
# =3D> 4
# irb(main):005:0> a.select { |key,value| value > 2 }
# =3D> [[3, 4]]
# irb(main):006:0> a.reject { |key,value| value <=3D 2 }
# =3D> {3=3D>4}

that will change in newer version of ruby, eg ruby1.9

irb(main):015:0> RUBY_VERSION
=3D> "1.9.0"
irb(main):016:0> a=3DHash.new
=3D> {}
irb(main):017:0> a[1]=3D2
=3D> 2
irb(main):018:0> a[2]=3D2
=3D> 2
irb(main):019:0> a[3]=3D4
=3D> 4
irb(main):020:0> a.select { |key,value| value > 2 }
=3D> {3=3D>4}
irb(main):021:0> a.reject { |key,value| value <=3D 2 }
=3D> {3=3D>4}

kind regards -botp

 
Reply With Quote
 
Srijayanth Sridhar
Guest
Posts: n/a
 
      07-01-2008
>
> 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?

Jayanth

 
Reply With Quote
 
David A. Black
Guest
Posts: n/a
 
      07-01-2008
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.

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

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.


David

--
Rails training from David A. Black and Ruby Power and Light:
Intro to Ruby on Rails July 21-24 Edison, NJ
Advancing With Rails August 18-21 Edison, NJ
See http://www.rubypal.com for details and updates!

 
Reply With Quote
 
Srijayanth Sridhar
Guest
Posts: n/a
 
      07-01-2008
Well put. Thanks again.

Jayanth

On Tue, Jul 1, 2008 at 6:18 PM, David A. Black <(E-Mail Removed)> 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.
>
> "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.
>
> 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.
>
>
> David
>
> --
> Rails training from David A. Black and Ruby Power and Light:
> Intro to Ruby on Rails July 21-24 Edison, NJ
> Advancing With Rails August 18-21 Edison, NJ
> See http://www.rubypal.com for details and updates!
>
>


 
Reply With Quote
 
Rick DeNatale
Guest
Posts: n/a
 
      07-01-2008
[Note: parts of this message were removed to make it a legal post.]

On Tue, Jul 1, 2008 at 8:48 AM, David A. Black <(E-Mail Removed)> 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/

 
Reply With Quote
 
Robert Dober
Guest
Posts: n/a
 
      07-01-2008
On Tue, Jul 1, 2008 at 3:42 PM, Rick DeNatale <(E-Mail Removed)> wrote:
I rather agree with Rick although David has a point too.

I therefore implemented hselect in Labrador (also kselect for keys and
vselect for values) all returning hashes. Parts of Labrador are
however highly experimental - and I intend to put some order into this
soon - therefore maybe you can find what you want in Facets which is a
highly tested and widely used framework or just borrow my code from
Labrador (BSD license).

HTH
Robert



--
http://ruby-smalltalk.blogspot.com/

---
AALST (n.) One who changes his name to be further to the front
D.Adams; The Meaning of LIFF

 
Reply With Quote
 
Srijayanth Sridhar
Guest
Posts: n/a
 
      07-01-2008
On Tue, Jul 1, 2008 at 7:26 PM, Robert Dober <(E-Mail Removed)> wrote:
> On Tue, Jul 1, 2008 at 3:42 PM, Rick DeNatale <(E-Mail Removed)> wrote:
> I rather agree with Rick although David has a point too.
>


Yeah I agree with Rick as well or I wouldn't have asked the question
in the first place.


> I therefore implemented hselect in Labrador (also kselect for keys and
> vselect for values) all returning hashes. Parts of Labrador are
> however highly experimental - and I intend to put some order into this
> soon - therefore maybe you can find what you want in Facets which is a
> highly tested and widely used framework or just borrow my code from
> Labrador (BSD license).
>


I am just hacking up the classes as of now. Don't really intend to use
it anywhere.

Thank you all,

Jayanth

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
unable to go "left" of an array, but yes "right" of an array Roger Pack Ruby 2 02-16-2010 04:08 PM
Sorted Returns List and Reversed Returns Iterator ++imanshu Python 7 08-23-2008 04:25 AM
createImage sometime returns null and sometime returns non-null. vizlab Java 3 10-17-2007 11:21 AM
block returns and hash element returns Trans Ruby 2 11-06-2005 12:15 PM



Advertisments