Given that a hash is not ordered, is this reliable?
h = { :a=>1, :b=>2 }
Struct.new(*h.keys).new(*h.values)
=> #<struct #Class:0xb7aead00 a=1, b=2>
T.
Given that a hash is not ordered, is this reliable?
h = { :a=>1, :b=>2 }
Struct.new(*h.keys).new(*h.values)
=> #<struct #Class:0xb7aead00 a=1, b=2>
T.
On Nov 17, 2007 5:47 PM, Trans [email protected] wrote:
Given that a hash is not ordered, is this reliable?
h = { :a=>1, :b=>2 }
Struct.new(*h.keys).new(*h.values)
=> #<struct #Class:0xb7aead00 a=1, b=2>
by definition not, I would never bet on it,
Knowing you I know that you probably know that you can do this
Struct.new( *(k = h.keys) ).new( *h.values_at( *k ) )
and are after something else, I however think that the above construct
might be of interest for other readers
However it seems that somehow it works in ruby and jruby
520/20 > ruby -v && jruby -v
ruby 1.8.6 (2007-06-07 patchlevel 36) [i486-linux]
ruby 1.8.5 (2007-11-01 rev 4842) [i386-jruby1.1b1]
521/21 > cat hash2strct.rb
require ‘test/unit’
class TestH2S < Test::Unit::TestCase
1000.times do |n|
define_method “test_%03d” % n do
h = Hash.new
n.succ.times do
h[“s#{rand(100)}”.to_sym] = Object.new
end
s = Struct.new( *h.keys ).new( *h.values )
s.each_pair do |k,|
assert_equal s[k], h[k]
end
end
end
end
robert@roma:~/log/ruby/ML 18:28:32
517/17 > ruby hash2strct.rb
Loaded suite hash2strct
Started
…
Finished in 14.821887 seconds.
1000 tests, 90011 assertions, 0 failures, 0 errors
robert@roma:~/log/ruby/ML 18:28:55
518/18 > jruby hash2strct.rb
Loaded suite hash2strct
Started
…
Finished in 31.693 seconds.
If you really want to use this, you need confirmation of a code Guru of
course.
Cheers
Robert
On Nov 17, 2007, at 6:54 PM, Robert D. wrote:
On Nov 17, 2007 5:47 PM, Trans [email protected] wrote:
Given that a hash is not ordered, is this reliable?
h = { :a=>1, :b=>2 }
Struct.new(*h.keys).new(*h.values)
=> #<struct #Class:0xb7aead00 a=1, b=2>
by definition not, I would never bet on it,
That’s guaranteed to work in Perl. Could it be the case that it works
but it is undocumented in Ruby?
– fxn
Hi,
At Sun, 18 Nov 2007 02:54:12 +0900,
Robert D. wrote in [ruby-talk:279478]:
On Nov 17, 2007 5:47 PM, Trans [email protected] wrote:
Given that a hash is not ordered, is this reliable?
h = { :a=>1, :b=>2 }
Struct.new(*h.keys).new(*h.values)
=> #<struct #Class:0xb7aead00 a=1, b=2>
by definition not, I would never bet on it,
Hash iterates in the definite order until it’s modified, not at
random each time. It’s just hard to predict. So it should
work if it’s not modified between getting keys and values.
Trans wrote:
Given that a hash is not ordered, is this reliable?
h = { :a=>1, :b=>2 }
Struct.new(*h.keys).new(*h.values)
=> #<struct #Class:0xb7aead00 a=1, b=2>
Code Snippet #1 on RubyForge.
http://rubyforge.org/snippet/detail.php?type=snippet&id=1
Regards,
Dan
On Nov 17, 2007 7:35 PM, Nobuyoshi N. [email protected] wrote:
by definition not, I would never bet on it,
Hash iterates in the definite order until it’s modified, not at
random each time. It’s just hard to predict. So it should
work if it’s not modified between getting keys and values.–
Nobu Nakada
Do you believe this behavior should be “defined” in other words if I
were writing my Ruby interpreter should I implement it this way?
Personally I think it is a little bit against Hash’s nature and (just
a joke Xavier) if Perl does it that way, shall we?
Cheers
Robert
On 11/17/07, Trans [email protected] wrote:
Given that a hash is not ordered, is this reliable?
h = { :a=>1, :b=>2 }
Struct.new(*h.keys).new(*h.values)
=> #<struct #Class:0xb7aead00 a=1, b=2>
It’s reliable; it’s not thread-safe (making it potentially unreliable).
-austin
On Nov 17, 2007 10:07 PM, Gregory S.
[email protected] wrote:
k,v = h.to_a.transpose
Struct.new(*k).new(*v)
that is nice
On Sun, Nov 18, 2007 at 01:47:53AM +0900, Trans wrote:
Given that a hash is not ordered, is this reliable?
h = { :a=>1, :b=>2 }
Struct.new(*h.keys).new(*h.values)
=> #<struct #Class:0xb7aead00 a=1, b=2>
It should work, but it causes me discomfort, too. I prefer this:
k,v = h.to_a.transpose
Struct.new(*k).new(*v)
T.
–Greg
On Nov 17, 2007, at 10:35 , Nobuyoshi N. wrote:
h = { :a=>1, :b=>2 }
Struct.new(*h.keys).new(*h.values)
=> #<struct #Class:0xb7aead00 a=1, b=2>
by definition not, I would never bet on it,Hash iterates in the definite order until it’s modified, not at
random each time. It’s just hard to predict. So it should
work if it’s not modified between getting keys and values.
Kinda makes me want a flag or environment variable that WILL iterate
through a hash randomly every time…
ruby --pain hash_to_struct.rb
should fail every time as written above.
It would help drive out a number of subtle and damn hard to debug bugs
out there.
On Nov 17, 5:23 pm, “Robert D.” [email protected] wrote:
Struct.new(*h.keys).new(*h.values)
=> #<struct #Class:0xb7aead00 a=1, b=2>It should work, but it causes me discomfort, too. I prefer this:
k,v = h.to_a.transpose
Struct.new(*k).new(*v)
that is nice
Thanks all. Good to understand --notably the thread safety. I’ll use
Robert’s or Greg’s suggestion.
Seems like it would be nice to have a way to generate a one time
Struct object like one can an OpenStruct. But in anycase…
Thanks,
T.
It’s “reliable” given the default implementation, but it is not
guaranteed for all implementations (even if the current jruby
implementaton works). Bottom line is, don’t rely on implementation
details for your code to go through (if you can help it).
Regards,
Jordan
On Nov 19, 3:15 am, MonkeeSage [email protected] wrote:
It’s “reliable” given the default implementation, but it is not
guaranteed for all implementations (even if the current jruby
implementaton works). Bottom line is, don’t rely on implementation
details for your code to go through (if you can help it).
Not for long though. I’m under the impression that as of 1.9,
insertion order is going to be “spec”.
T.
On Nov 19, 5:58 am, Trans [email protected] wrote:
T.
Yeah, but that’s still just Nobu’s implementation. Until we have a
solid, implementation independent grammar (http://rubyforge.org/
projects/rubygrammar seems to be stalled), you’re relying on
implementation details. But that may be all we have for a while. As
long as you’re aware of that fact, go for it.
Regards,
Jordan
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs