Seesm like there should be a mehtod for this:
h = { :a=>1, :b=>2, :c=>3 }
h.what_method(:a, :c) #=> { :a=>1, :c=>3 }
^^^^^^^^^^^
Or is there some other simple way we're supposed to do this?
T.
http://concentrationstudios.com/2006/12/20/12-days-of-stupid-ruby-tricks
Check out Day 11
···
On 1/20/07, Trans <transfire@gmail.com> wrote:
Seesm like there should be a mehtod for this:
h = { :a=>1, :b=>2, :c=>3 }
h.what_method(:a, :c) #=> { :a=>1, :c=>3 }
^^^^^^^^^^^Or is there some other simple way we're supposed to do this?
T.
--
Chris Carter
concentrationstudios.com
brynmawrcs.com
Trans wrote:
Seesm like there should be a mehtod for this:
h = { :a=>1, :b=>2, :c=>3 }
h.what_method(:a, :c) #=> { :a=>1, :c=>3 }
^^^^^^^^^^^Or is there some other simple way we're supposed to do this?
T.
h = { :a,1, :b,2, :c,3 }
==>{:c=>3, :a=>1, :b=>2}
h.reject{|k,v| ![:a,:c].include? k}
==>{:c=>3, :a=>1}
Trans wrote:
Seesm like there should be a mehtod for this:
h = { :a=>1, :b=>2, :c=>3 }
h.what_method(:a, :c) #=> { :a=>1, :c=>3 }
^^^^^^^^^^^Or is there some other simple way we're supposed to do this?
T.
h = { :a=>1, :b=>2, :c=>3 }
class Hash
def restrict(*keys)
keys.inject({}) {|h,k| h[k] = self[k]; h}
# alternative:
#Hash[*keys.zip(values_at(*keys)).flatten]
end
end
p h.restrict(:a, :c) #=> { :a=>1, :c=>3 }
Maybe there should be something like this in the core?
···
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
I will try to answer your question, but still it will be more questions 
Before thinking about the name, naming really is an art, I am thinking about
the interface
(1) So there is *args as above
(2) Any object responding to #include?
We need two names now, great job Robert 
(1)
#grep, wait a minute hash objects already have grep via Enumerable, no idea
how it works for hashes though
#filter or filter_keys
#intersect might just be the wrong name
#delete_unless ugly because delete_if takes a block form only
my candidate is
#for_keys
{a=>1, b=>2, c=>3}.for_keys("hi", :alpha) => {"hi" => 2} # for some
values of a, b and c
Now to
(2)
#for_keys_from consistent but long (even ugly)
#keys_from
#intersect
#use_keys
#shadow maybe
a different approach would be to define a method in Enumerable
Enumerable#shadow_hash
[*1..2].shadow_hash {a=>2, b=>3, c=>5, d=>7, e=>11} => {1=>2, 2=>3} # see
above
this allows even for a call without the accolades.
This all very vague but I feel that such methods would be very useful.
Cheers
Robert
···
On 1/21/07, Trans <transfire@gmail.com> wrote:
Seesm like there should be a mehtod for this:
h = { :a=>1, :b=>2, :c=>3 }
h.what_method(:a, :c) #=> { :a=>1, :c=>3 }
^^^^^^^^^^^Or is there some other simple way we're supposed to do this?
T.
--
"The best way to predict the future is to invent it."
- Alan Kay
Trans ha escrito:
Seesm like there should be a mehtod for this:
No.
Or is there some other simple way we're supposed to do this?
T.
[:a, :c].inject({}) { |s, x| s = h; s }
Trans wrote:
Seesm like there should be a mehtod for this:
h = { :a=>1, :b=>2, :c=>3 }
h.what_method(:a, :c) #=> { :a=>1, :c=>3 }
^^^^^^^^^^^
# h = { :a=>'a', :b=>'b', :c=>'c' }
# p h.entries( :a, :c, :d )
# #=> { :d=>nil, :a=>'a', :c=>'c' }
class Hash
def entries( *keys )
self.class[ *keys.zip( values_at( *keys ) ).flatten ]
end
end
STOP PRESS
#pairs_at is much better than anything I came up with, just can't read
···
On 1/21/07, Robert Dober <robert.dober@gmail.com> wrote:
On 1/21/07, Trans <transfire@gmail.com> wrote:
--
"The best way to predict the future is to invent it."
- Alan Kay
gga wrote:
Trans ha escrito:
> Seesm like there should be a mehtod for this:No.
That being said, Hash DOES seem to be buggy and missing a proper
find_all method.
h.find_all { |k,v| [:a,:c].include?(k) }
=> [[:c, 3], [:a, 1]] # incorrect, it is returning an array, not a
hash
h.reject { |k,v| ![:a,:c].include?(k) }
{:c=>3, :a=>1} # correct
Assuming this is a frequently used idiom you'd not prefer to see
h.pairs_at(:a, :c)
instead of the above?
Astonishes me.
Cheers
Robert
···
On 1/21/07, gga <GGarramuno@aol.com> wrote:
Trans ha escrito:
> Seesm like there should be a mehtod for this:No.
>
> Or is there some other simple way we're supposed to do this?
>
> T.[:a, :c].inject({}) { |s, x| s = h; s }
--
"The best way to predict the future is to invent it."
- Alan Kay
Phrogz wrote:
Trans wrote:
> Seems like there should be a mehtod for this:
class Hash
def entries( *keys )
self.class[ *keys.zip( values_at( *keys ) ).flatten ]
end
end
Oh, and yes: I'd like a method like this in the core, also. Preferably
with a more elegant, faster implementation than the above. I find this
quite useful sometimes. A recent example that comes to mind is taking
the params hash in Rails and specifying a specific subset of the
populated values to pass on to another method.
Hi --
···
On Mon, 22 Jan 2007, Phrogz wrote:
Phrogz wrote:
Trans wrote:
Seems like there should be a mehtod for this:
class Hash
def entries( *keys )
self.class[ *keys.zip( values_at( *keys ) ).flatten ]
end
endOh, and yes: I'd like a method like this in the core, also. Preferably
with a more elegant, faster implementation than the above. I find this
quite useful sometimes. A recent example that comes to mind is taking
the params hash in Rails and specifying a specific subset of the
populated values to pass on to another method.
I'll put in a plug here for flattenx, which lets you flatten by any
number of levels so that you could do the above without the
over-flattening vulnerability.
http://raa.ruby-lang.org/project/flattenx/
David
--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black\)
(See what readers are saying! http://www.rubypal.com/r4rrevs.pdf\)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)
Hi --
gga wrote:
Trans ha escrito:
Seesm like there should be a mehtod for this:
No.
That being said, Hash DOES seem to be buggy and missing a proper
find_all method.> h.find_all { |k,v| [:a,:c].include?(k) }
=> [[:c, 3], [:a, 1]] # incorrect, it is returning an array, not a
hash
It's not incorrect or buggy; that's the way Enumerable#find_all works.
In addition to being Enumerables themselves, arrays serve as the
common container for the results of lots of different Enumerables.
It could work otherwise (at least for hashes, though not in the
general Enumerable case), but it works this way by design, not by
accident.
David
···
On Sun, 21 Jan 2007, gga wrote:
--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black\)
(See what readers are saying! http://www.rubypal.com/r4rrevs.pdf\)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)
Yes, yes! I've used this locally, and wanted to rely on this remotely,
many times!
This, too, should be in the core (particularly since it requires
compilation, and is not a pure-ruby solution.)
···
dbl...@wobblini.net wrote:
I'll put in a plug here for flattenx, which lets you flatten by any
number of levels so that you could do the above without the
over-flattening vulnerability.
I'd rather see it in the core
I have a slight preference for #pairs_at, #entries is not a bad name, but I
feel the first is more descriptive.
Cheers
Robert
···
On 1/21/07, dblack@wobblini.net <dblack@wobblini.net> wrote:
Hi --
On Mon, 22 Jan 2007, Phrogz wrote:
> Phrogz wrote:
>> Trans wrote:
>>> Seems like there should be a mehtod for this:
>> class Hash
>> def entries( *keys )
>> self.class[ *keys.zip( values_at( *keys ) ).flatten ]
>> end
>> end
>
> Oh, and yes: I'd like a method like this in the core, also. Preferably
> with a more elegant, faster implementation than the above. I find this
> quite useful sometimes. A recent example that comes to mind is taking
> the params hash in Rails and specifying a specific subset of the
> populated values to pass on to another method.I'll put in a plug here for flattenx, which lets you flatten by any
number of levels so that you could do the above without the
over-flattening vulnerability.
--
"The best way to predict the future is to invent it."
- Alan Kay
dblack@wobblini.net wrote:
Hi --
> Phrogz wrote:
>> Trans wrote:
>>> Seems like there should be a mehtod for this:
>> class Hash
>> def entries( *keys )
>> self.class[ *keys.zip( values_at( *keys ) ).flatten ]
>> end
>> end
>
> Oh, and yes: I'd like a method like this in the core, also. Preferably
> with a more elegant, faster implementation than the above. I find this
> quite useful sometimes. A recent example that comes to mind is taking
> the params hash in Rails and specifying a specific subset of the
> populated values to pass on to another method.I'll put in a plug here for flattenx, which lets you flatten by any
number of levels so that you could do the above without the
over-flattening vulnerability.
class Array
def flatten_1
inject(){|a,x| Array(x).each{|e| a<<e}; a}
end
end
p [[[[22],33],44], %w(aa bb cc), [88,[99,55]], 3.14].flatten_1
--- output -----
[[[22], 33], 44, "aa", "bb", "cc", 88, [99, 55], 3.14]
···
On Mon, 22 Jan 2007, Phrogz wrote:
Robert Dober wrote:
I'd rather see it in the core
I have a slight preference for #pairs_at, #entries is not a bad name, but I
feel the first is more descriptive.
I agree. I think #paris_at is easier to quicky comprehend.
Also, I recalled I had added another method to facets that can do this
too. I was writing Hash#| and thought I should go ahead and wrote an #&
too if reasonable. And lo! There it was:
h = {:a=>1,:b=>2,:c=>3}
h & [:a,:b] #=> {:a=>1,:b=>2}
Code for facets/core/hash/op_and.rb (also op_or.rb):
class Hash
def &(other)
case other
when Array
k = (keys & other)
Hash[*(k.zip(values_at(*k)).flatten)]
else
Hash.new[*(to_a & other.to_a).flatten]
end
end
def |(other)
other.merge self
end
end
Think I still prefer the readability of #pairs_at however. But the
above is good to have too.
T.
dblack@wobblini.net wrote:
It's not incorrect or buggy; that's the way Enumerable#find_all works.
In addition to being Enumerables themselves, arrays serve as the
common container for the results of lots of different Enumerables.
Sorry, David, but I disagree. It may not be buggy (as the bugginess is
properly documented :), but it is certainly incorrect. Re-read my
post.
Hash.reject, which is also an Enumerable, DOES return a hash.
Hash.find_all which is algorithmically the same as Hash.reject but
without a negation, does not.
Someone forgot to override find_all in the Hash case, but did remember
to do it for Hash.reject. Or, if you are of the belief that indeed
Enumerables should always return an array, Hash.reject was incorrectly
overridden when it shouldn't have been.
Hi --
···
On Mon, 22 Jan 2007, William James wrote:
dblack@wobblini.net wrote:
I'll put in a plug here for flattenx, which lets you flatten by any
number of levels so that you could do the above without the
over-flattening vulnerability.class Array
def flatten_1
inject(){|a,x| Array(x).each{|e| a<<e}; a}
end
endp [[[[22],33],44], %w(aa bb cc), [88,[99,55]], 3.14].flatten_1
--- output -----
[[[22], 33], 44, "aa", "bb", "cc", 88, [99, 55], 3.14]
That's the idea, though flattenx lets you do flatten_by(n) and also is
written in C for speed.
David
--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black\)
(See what readers are saying! http://www.rubypal.com/r4rrevs.pdf\)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)
syntactic sugar kind of spoils us, ( I remember how happy I was about C++ in
the first please because I could write
whatever_object + another_object well I was young and stupid than, now of
course I am older ;).
It is really your posts who brought it up, it is so natural to want to have
consistent notation.
But sometimes I really think Ruby would be better a language without
Array#<< Proc# etc. etc
Why is there not a Array#>> for #pop, these are very reasonable questions a
new Ruby user will ask!.
If we would have one way to call a proc, one way to push to an array, things
would be simpler.
I *still* agree that now, gotten used to it, << is very, very readable (I
*never* use #push), but I am starting to wonder if I am not mistaken?
In that spirit I guess #pairs_at is really much more readable, we should use
Programming Jargon, not Ruby Jargon (although it gives this warm fuzzy
feeling, I agree!!!!).
Cheers
Robert
···
On 1/21/07, Trans <transfire@gmail.com> wrote:
Robert Dober wrote:
<snip>
Think I still prefer the readability of #pairs_at however. But the
above is good to have too.T.
The more I think about it the more I like the Smalltalk approach, the
--
"The best way to predict the future is to invent it."
- Alan Kay