Arrays and Hashes

[Abder-rahman Ali]

In "Why's poignant guide to Ruby" it mentions the following:

Unlike arrays, the items in a hash are not kept in a specific order.

Can you clarify on this?

Thanks.

 

[Jacob Mitchell]

[Note: parts of this message were removed to make it a legal post.]

Arrays have order because each one represents a sequence of objects. This
guarantees that for a given array you'll get consistent results using the
"each" method:

a = [1,2,3]
a.each {|n| puts n} #you'll always get 1 2 and 3 in that order

Hashes, on the other hand, are more about letting you map some object, the
key, to another object, the value. A single hash can have several of these
mappings, but the "order" of the mappings is insignificant and therefore not
necessarily consistent.

{:a => 1, :b => 2, :c => 3} == {:b => 2, :a => 1, :c => 3} # true

Although all of the the "each" methods provided by a hash ("each",
"each_pair", etc.) return items in a sequence, that sequence isn't
guaranteed to be the same every time.

Hope that helps.

-Jake

On Mon, Jul 12, 2010 at 8:22 AM, Abder-rahman Ali <

 

[Phrogz]

Unlike arrays, the items in a hash are not kept in a specific order.

Note that this is no longer true in Ruby 1.9. Insertion order,
including initialization, is maintained for Hashes:


Slim2:~ phrogz$ irb --simple-prompt

h = { a:1, z:7 } => {:a=>1, :z=>7}
h[:f] = 14; h[:b] = 99 => 99
h['last'] = "this one" => "this one"
h[-1] = "really last" => "really last"
h.each{ |k,v| p [k,v] }

[:a, 1]
[:z, 7]
[:f, 14]
[:b, 99]
["last", "this one"]
[-1, "really last"]
=> {:a=>1, :z=>7, :f=>14, :b=>99, "last"=>"this one", -1=>"really
last"}=> [:a, :z, :f, :b, "last", -1]

 

[Abder-rahman Ali]

Unlike arrays, the items in a hash are not kept in a specific order.

Note that this is no longer true in Ruby 1.9. Insertion order,
including initialization, is maintained for Hashes:


Slim2:~ phrogz$ irb --simple-prompt

h = { a:1, z:7 } => {:a=>1, :z=>7}
h[:f] = 14; h[:b] = 99 => 99
h['last'] = "this one" => "this one"
h[-1] = "really last" => "really last"
h.each{ |k,v| p [k,v] }

[:a, 1]
[:z, 7]
[:f, 14]
[:b, 99]
["last", "this one"]
[-1, "really last"]
=> {:a=>1, :z=>7, :f=>14, :b=>99, "last"=>"this one", -1=>"really
last"}=> [:a, :z, :f, :b, "last", -1]

Thanks a lot Gavin.

I may not getting your point clear. What is it not applicable to Ruby
1.9 from what Jake said?

 

[Jacob Mitchell]

[Note: parts of this message were removed to make it a legal post.]

I may not getting your point clear. What is it not applicable to Ruby
1.9 from what Jake said?

Ruby 1.9 added a constraint that whenever you query for an iterator using

any of the Hashes each* methods, you'll always get the objects in the same
order that they were inserted into that hash. Prior to that there were no
promises about the order the elements would be yielded by the iterator.

-Jake

 

[Abder-rahman Ali]

any of the Hashes each* methods, you'll always get the objects in the
same
order that they were inserted into that hash. Prior to that there were
no
promises about the order the elements would be yielded by the iterator.

-Jake

I got you Jake. Thanks.

 

[Julian Leviston]

Yes. An orderedhash object is present in libraries such as activesupport bec=
ause this feature can be useful. Its not very often that you need it ordered=
but every now and then it can come in handy.=20

I sometimes wish ruby had the rich tapestry of collection types that smallta=
lks such as gemstone avail their users of. For example, a bag is an unordere=
d collection. Some collections don't allow multiples, others are faster... E=
tc

Blog: http://random8.zenunit.com/
Twitter: http://twitter.com/random8r
Learn: http://sensei.zenunit.com/
New video up now at http://sensei.zenunit.com/ real fastcgi rails deploy pro=
cess! Check it out now!

On 2010-07-12 12:01:20 -0700, Jacob Mitchell said:
=20

[Note: parts of this message were removed to make it a legal post.]

I may not getting your point clear. What is it not applicable to Ruby
1.9 from what Jake said?
Ruby 1.9 added a constraint that whenever you query for an iterator usin=

g
any of the Hashes each* methods, you'll always get the objects in the sam= e
order that they were inserted into that hash. Prior to that there were n= o
promises about the order the elements would be yielded by the iterator.
-Jake

=20
In practice, hash order (for 1.8) is deterministic *per machine*, meaning t=

he hash will enumerate in the same order each time for you, but not in the s=
ame order as someone else's machine.

=20
That said, this must not be relied on (after all, it isn't in the spec). O=

ne should not expect hashes to be ordered, and any code in Ruby 1.8 that tre=
ats the order of a hash as significant is incorrect.