Hi folks, I know that this is a really simple question, and there must
be many ways to do it in Ruby… but what I’m looking for is an
elegant way to take a collection of objects and create a hash mapping
one attribute of the object as the key and the other as the value. So
far what I am doing is this:
@objects.each do |object|
myHash[ object.key ] = object.value
end
I played around with doing something like:
@myHash = objects.map do |object| [ object.key => object.value ] end
But that returns an array of single-value hashes, which is not exactly
what I am trying to do.
I know this is a stupid question, and probably pointless because I do
know ways to do it, but I would really like the know the Ruby Way to do
this. Ruby seems so given to elegant code that my code above really
bugs me for some reason.
myHash[ object.key ] = object.value
know ways to do it, but I would really like the know the Ruby Way to do
this. Ruby seems so given to elegant code that my code above really
bugs me for some reason.
Thanks all!
-Will
There are no stupid questions, only stupid people.
The solution you first wrote where you’re iterating over the array is as
good as any, i would probably use that.
If you like Ever So Cool one-liners, this one might also work:
It does pretty much completely the same, except were this Smalltalk, the
block wouldn’t be a closure and therefore a horse’s butthair more
memory-efficient solution.
Oh, not quite, that was just a general random piece of Zen. (read: brain
fart).
But indeed -part- of the meaning was that you can’t indeed ask stupid
questions. For given values of ‘question’
Green eggs and spam.
David V.
Shouldn’t turn Thunderbird on when insomniac…
It does pretty much completely the same, except were this
Smalltalk, the block wouldn’t be a closure and therefore a horse’s
butthair more memory-efficient solution.
Is this because the Smalltalk compiler will notice that there are no
references to variables outside the block and Ruby’s current
implementation
will not notice the same thing?
h = objects.inject({}){|h,o| h.update o.key => o.value}
-a
Oooh, Spiffy ™ Wish I thought of that. Possibly less efficient
though generating a lot of single-pair hashes that are instant garbage,
although it’s all fun and games until someone runs a benchmark.
myHash[ object.key ] = object.value
know ways to do it, but I would really like the know the Ruby Way to do
this. Ruby seems so given to elegant code that my code above really
bugs me for some reason.
Thanks all!
h = objects.inject({}){|h,o| h.update o.key => o.value}
myHash[ object.key ] = object.value
know ways to do it, but I would really like the know the Ruby Way to do
this. Ruby seems so given to elegant code that my code above really
bugs me for some reason.
Stupid questions (i.e. the asking of) are my speciality these days (
)
and this doesn’t seem to be a particularly dumb one to me You are
right though about a more elegant way to do it:
On Wed, 11 Jan 2006 09:23:04 -0000, Ross B. [email protected] wrote:
I know this is a stupid question, and probably pointless because I do
know ways to do it, but I would really like the know the Ruby Way to do
this. Ruby seems so given to elegant code that my code above really
bugs me for some reason.
Stupid questions (i.e. the asking of) are my speciality these days
( ) and this doesn’t seem to be a particularly dumb one to me You
are right though about a more elegant way to do it:
Stupid answers, too. Seems I misread the question, sorry about that
(Sorry everyone for all this noise lately, I promise I’m going to start
enforcing a fifteen minute gap between writing and posting to try and
make
sure I’m not just spouting crap again).
Is this because the Smalltalk compiler will notice that there are no
references to variables outside the block and Ruby’s current
implementation
will not notice the same thing?
Gary W.
Quite so, Smalltalk compilers could optimize blocks that obviously
didn’t close upon the lexical environment by dropping part or all of the
lexical binding. There was a thread about procs being a potential memory
leak on the list that discussed this in Ruby, you might want to look at
the ML archives.
One of the arguments raised in the thread was that this optimization
isn’t really in Ruby because of eval. When blocks are called, they have
to be (usually) executed in the lexical scope in which they were
defined. The same is true of eval. Unfortunately, it’s harder to
determine what in the surrounding scope is referenced in an eval call
than in a block, since the code is parsed at runtime; also you can’t
really determine when eval is called because of aliasing. Therefore
optimizing the blocks would very likely break the use of eval in them.
I don’t know what conclusion the original discussion came to, I’d
personally like to see eval mildly deprecated in favor of the many
other, more explicit, and cleaner reflection capacities like #class_eval
and #define_method for code generation, discouraged for use in the
standard library, and optimizing the blocks as optional interpreter /
VM.
So we map the objects into array pairs of the key and value, flatten
the resulting array, and then use the “splat” operator (*) to turn
those into parameters to the Hash::[] method.
Ryan
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Wish I thought of that. Possibly less efficient