Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > Hash pairs at?

Reply
Thread Tools

Hash pairs at?

 
 
Alex LeDonne
Guest
Posts: n/a
 
      01-22-2007
On 1/21/07, Trans <(E-Mail Removed)> wrote:
>
> http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> > Hi --
> >
> > On Mon, 22 Jan 2007, Joel VanderWerf wrote:
> >
> > > gga wrote:
> > >> (E-Mail Removed) 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.
> > >
> > > This does look a bit odd...
> > >
> > > irb(main):001:0> h = {1=>3, 5=>7}
> > > => {5=>7, 1=>3}
> > > irb(main):002:0> h.reject {|k,v| k==1}
> > > => {5=>7}
> > > irb(main):003:0> h.select {|k,v| k==1}
> > > => [[1, 3]]

> >
> > A bit. The funny thing, though, is that it of course makes it
> > possible to do either -- so the irregularity actually provides a kind
> > of resilience. The consistent version, should it ever come into
> > being, will shut the door on one of them.
> >
> > I know that people don't want to do select { not } and so on... so
> > I can see that it's not really ideal. But it's kind of fascinating
> > that "fixing" it, in either direction, would result in a net loss of
> > functionality.

>
> Avoiding net loss, how about going for gross gain. So how about "fixing
> it" so there is both?
>
> select
> select_pair
>
> And {meth}_pair could also work for assoc arrays too.
>
> T.
>


Maybe I'm late to the party, but instead of select_pair, I'd name the
method slice, analagous to Array#slice.

 
Reply With Quote
 
 
 
 
Joel VanderWerf
Guest
Posts: n/a
 
      01-22-2007
Alex LeDonne wrote:
> Maybe I'm late to the party, but instead of select_pair, I'd name the
> method slice, analagous to Array#slice.


Looks like the rails crowd has beaten us to it:

http://dev.rubyonrails.org/changeset/5726

It might be in facets, too.

Seems like a good name for a good method.

--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

 
Reply With Quote
 
 
 
 
Trans
Guest
Posts: n/a
 
      01-22-2007

Joel VanderWerf wrote:
> Alex LeDonne wrote:
> > Maybe I'm late to the party, but instead of select_pair, I'd name the
> > method slice, analagous to Array#slice.

>
> Looks like the rails crowd has beaten us to it:
>
> http://dev.rubyonrails.org/changeset/5726
>
> It might be in facets, too.
>
> Seems like a good name for a good method.


hmm... in Facets, Hash#slice is just an alias for Hash#values_at.
#slice is a reasonably good name. however I suggested #select_pair, not
as a name for #pairs_at, but as a hash equivalent of #select, to enrich
the langauge with greater polymorphism between hash and asscocivtive
arrays.

{:a=>1, :b=>2}.select{ |k,v| k == :a } #=> [[:a=>1]]
[ [:a, 1], [:b, 2] ].select{ |k,v| k == :a } #=> [[:a=>1]]

{:a=>1, :b=>2}.select_pair{ |k,v| k == :a } #=> { :a=>1 }
[ [:a, 1], [:b, 2] ].select_pair{ |k,v| k == :a } #=> { :a=>1 }

Most of the normal enumerable each-related methods could have hash
equivalents like this.

(I'm not partial to the _pair suffix, but for lack of a better term...)

T.


 
Reply With Quote
 
Florian Frank
Guest
Posts: n/a
 
      01-23-2007
Joel VanderWerf wrote:
> Alex LeDonne wrote:
>> Maybe I'm late to the party, but instead of select_pair, I'd name the
>> method slice, analagous to Array#slice.

>
> Looks like the rails crowd has beaten us to it:
>
> http://dev.rubyonrails.org/changeset/5726
>
> It might be in facets, too.
>
> Seems like a good name for a good method.
>


I called it 'extract' and use this:

module HashInclusion
# Extract a hash out of this hash, that only contains key-value pairs
# matching _patterns_ and return it. _patterns_ can be for example /^foo/
# to extract 'foobar' and 'foobaz' or 'foo'/:foo to extract 'foo'.
def extract(*patterns)
patterns.map! { |pat| pat.respond_to?(:match) ? pat : pat.to_s }
result = default_proc ? self.class.new(&default_proc) :
self.class.new(default)
each { |k, v| result[k] = v if patterns.any? { |pat| pat === k.to_s } }
result
end
end

class ::Hash
include HashInclusion
end

The duck typing is a bit fishy, but it's possible to add pattern
objects, that implement #=== and #match this way. Coincidently this is
the case for Regex instances.

It's also interesting, that it's quite difficult to create an empty
"copy" of a given hash in Ruby, without duping and clearing it.

--
Florian Frank

 
Reply With Quote
 
Ken Bloom
Guest
Posts: n/a
 
      01-23-2007
On Mon, 22 Jan 2007 05:58:25 +0900, dblack wrote:

> Hi --
>
> On Mon, 22 Jan 2007, Joel VanderWerf wrote:
>
>> gga wrote:
>>> (E-Mail Removed) 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.

>>
>> This does look a bit odd...
>>
>> irb(main):001:0> h = {1=>3, 5=>7}
>> => {5=>7, 1=>3}
>> irb(main):002:0> h.reject {|k,v| k==1}
>> => {5=>7}
>> irb(main):003:0> h.select {|k,v| k==1}
>> => [[1, 3]]

>
> A bit. The funny thing, though, is that it of course makes it
> possible to do either -- so the irregularity actually provides a kind
> of resilience. The consistent version, should it ever come into
> being, will shut the door on one of them.
>
> I know that people don't want to do select { not } and so on... so
> I can see that it's not really ideal. But it's kind of fascinating
> that "fixing" it, in either direction, would result in a net loss of
> functionality.


No it wouldn't because you could just call .to_a on the returned hash to
get the nested array representation.

--Ken

--
Ken Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.
http://www.iit.edu/~kbloom1/
 
Reply With Quote
 
Trans
Guest
Posts: n/a
 
      01-23-2007

Ken Bloom wrote:
> On Mon, 22 Jan 2007 05:58:25 +0900, dblack wrote:
>
> > Hi --
> >
> > On Mon, 22 Jan 2007, Joel VanderWerf wrote:
> >
> >> gga wrote:
> >>> (E-Mail Removed) 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.
> >>
> >> This does look a bit odd...
> >>
> >> irb(main):001:0> h = {1=>3, 5=>7}
> >> => {5=>7, 1=>3}
> >> irb(main):002:0> h.reject {|k,v| k==1}
> >> => {5=>7}
> >> irb(main):003:0> h.select {|k,v| k==1}
> >> => [[1, 3]]

> >
> > A bit. The funny thing, though, is that it of course makes it
> > possible to do either -- so the irregularity actually provides a kind
> > of resilience. The consistent version, should it ever come into
> > being, will shut the door on one of them.
> >
> > I know that people don't want to do select { not } and so on... so
> > I can see that it's not really ideal. But it's kind of fascinating
> > that "fixing" it, in either direction, would result in a net loss of
> > functionality.

>
> No it wouldn't because you could just call .to_a on the returned hash to
> get the nested array representation.


that's a good point.

the downside however is that we would always have to use #to_a to
ensure polymorphism between assoc array and hash. so it's a bit of an
anti-duck. (array doesn't have a reciporcal #to_h either btw, though
that would be nice in itself!)

T.


 
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
hash of hash of hash of hash in c++ rp C++ 1 11-10-2011 04:45 PM
replace lines in a file using hash key-value pairs Johan Martinez Ruby 3 05-22-2011 03:07 AM
function to select only certain key/value pairs from hash? Aryk Grosz Ruby 13 11-18-2008 12:39 PM
Hash#select returns an array but Hash#reject returns a hash... Srijayanth Sridhar Ruby 19 07-02-2008 12:49 PM
sort multi-key hash by value and print out with key value pairs Antonio Quinonez Perl Misc 2 08-14-2003 10:56 PM



Advertisments