Hash pairs at?

ruby-talk
21

gga 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]]

···

dblack@wobblini.net wrote:

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

22

I didn't see anyone else mention that in Ruby 1.9...

$ ri-1.9 Array#flatten
---------------------------------------------------------- Array#flatten
      array.flatten -> an_array
      array.flatten(level) -> an_array

···

On Jan 21, 2007, at 3:50 PM, dblack@wobblini.net wrote:

That's the idea, though flattenx lets you do flatten_by(n) and also is
written in C for speed.

------------------------------------------------------------------------
      Returns a new array that is a one-dimensional flattening of this
      array (recursively). That is, for every element that is an array,
      extract its elements into the new array. If the optional _level_
      argument determins the level of recursion to flatten.

Gary Wright

23

Hi --

gga 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.

David

···

On Mon, 22 Jan 2007, Joel VanderWerf wrote:

dblack@wobblini.net 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)

24

Hi --

···

On Mon, 22 Jan 2007, gwtmp01@mac.com wrote:

On Jan 21, 2007, at 3:50 PM, dblack@wobblini.net wrote:

That's the idea, though flattenx lets you do flatten_by(n) and also is
written in C for speed.

I didn't see anyone else mention that in Ruby 1.9...

$ ri-1.9 Array#flatten
---------------------------------------------------------- Array#flatten
    array.flatten -> an_array
    array.flatten(level) -> an_array
------------------------------------------------------------------------
    Returns a new array that is a one-dimensional flattening of this
    array (recursively). That is, for every element that is an array,
    extract its elements into the new array. If the optional _level_
    argument determins the level of recursion to flatten.

Cool! I actually didn't know that had made it into 1.9. I look
forward to retiring flattenx :slight_smile:

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)

25

dblack@wobblini.net wrote:

Hi --

> gga 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.

···

On Mon, 22 Jan 2007, Joel VanderWerf wrote:
>> dblack@wobblini.net wrote:

26

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

--Ken

···

On Mon, 22 Jan 2007 05:58:25 +0900, dblack wrote:

Hi --

On Mon, 22 Jan 2007, Joel VanderWerf wrote:

gga wrote:

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.

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.

--
Ken Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.
http://www.iit.edu/~kbloom1/

27

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

···

On 1/21/07, Trans <transfire@gmail.com> wrote:

dblack@wobblini.net wrote:
> Hi --
>
> On Mon, 22 Jan 2007, Joel VanderWerf wrote:
>
> > gga wrote:
> >> 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.
> >
> > 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.

28

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:
>>> 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.
>>
>> 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.

29

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

30

And I have to agree that it is not a bad name, I still favor pairs_at, but
only because I am stubborn :wink:

···

On 1/22/07, Joel VanderWerf <vjoel@path.berkeley.edu> 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.

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

--
"The best way to predict the future is to invent it."
- Alan Kay

31

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.

32

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